vitor

But it also requires adding icons to each Keyword, and keeping the Workflow up-to-date as you remove apps from your system.

That always pastes as plain text. Which means it uses the formatting of the text around it, which might be what’s confusing you.

Simple to make as a Workflow. Connect a Hotkey Trigger (with Argument set to macOS Clipboard Contents) to a Copy to Clipboard Output (with Automatically paste to front most app ticked). On the Alfred Feature Suggestions forum. But seeing as it’s so simple to achieve as a Workflow, I’d say it’s unlikely it would be accepted as a new feature.

You’ll have to be more specific about what you’re doing and what’s (not) happening. Preferably with a video. You can record your screen with QuickTime Player. It’s important you make it on Mojave, as I don’t have (nor will I ever install of my own volition) Catalina on my main machine, so I can’t debug there.

That’s the way. Your problem is in how you’re doing it. Get rid of the Run Script; you need to run the code in the Script Filter. Connect your Keyword to an Arg and Vars, saving {query} to a variable and making Argument empty. Connect that to the Script Filter and make that run the code, but as an argument give it the variable you saved instead of {query} or a positional argument ($1).

Welcome @nutnutwin, That feature isn’t available, no.

Welcome @nemosmith, Tag of add Spotlight comments to your apps, and Alfred will find them by those keywords.

No, but some people used to make Script Filters in a way they would only run after you typed a period. Make your script exit early unless the last character is a period. When the caracter is a period, strip it from the argument and run the rest of the script. But a better way would be to click on Run Behaviour in your Script Filter window and change Queue Delay. After you connect two nodes, you’ll see some connecting lines will have a circle in the middle. Double-click it and tick Don’t close the Alfred window on actioning result to keep the window open. Stick an Argument and Variables Utility node in between them and delete the Argument.

Welcome @tylast, Reading a local database is likely to be more error-prone than using the API, because it will be undocumented, may cause corruption if you’re writing to it, and may require chasing a changing format. Coincidentally, someone posted something after your request, though it’s essentially a web search.

The issue isn’t Alfred, it’s Firefox. Firefox is a terrible browser for any kind of automation (at least on macOS). As another example, it’s the only major browser that doesn’t support AppleScript. Unfortunately, the developers at Mozilla consider those “features for power users that regular users don’t care about” (I’m paraphrasing, but that reason has been given to me) and fail to understand that power users build on those, allowing new abilities for regular users. They complain that nobody uses Firefox, but when you explain why (on macOS there are several things that do not exist or don’t work properly), they mostly ignore it. There’s only so much we can do. You need to make your voice heard on Firefox’s side, not on the side of the tools that don’t support Firefox, because those mostly don’t lack Firefox support by choice, they lack it because Firefox makes it hard or impossible.

I missed that on the screenshot. Though I also use ZSH as my shell (and have been doing so for years) I fall back on those habits because I still write scripts in Bash since ShellCheck—my favourite linter in any language—doesn’t support the former. Still, one thing you learn fast with shell scripts is you can never have too much quoting! Fun tangential fact, which I’m not sure I’ve shared before: back in April I opened a radar suggesting changing the default shell to ZSH. It was closed with “there are no plans to address this”. Talk about lack of communication between teams.

Ah, since the AppleScript was looping through a file list, I was unsure if the tool supported multiple paths at once. $@ should be quoted ("$@"), to prevent resplitting arguments.

Let’s look at it in parts: First, when asking for help with a Workflow, please upload it somewhere as we can’t properly help you without access to it. There are multiple places where your code or Workflow setup may be going wrong. Without looking at it we’re mostly shooting in the dark. On to the bash code, since @deanishe already dealt with the AppleScript part: query="{query}" That line means {query} and ${query} (same as $query) will be the same. This is both unnecessary and a source of confusion. There’s no reason to have two pieces of code with the same exact value, especially when they have similar names. Also, avoid with input as {query} (at the top of the script box), as it’s a legacy option that requires escaping depending on the language; use with input as argv instead, which is clearer and less prone to errors. With that setting, your first line would instead be query="${1}" (same as query="$1"). But again, there’s no point in that for so little code, use ${1} directly. Alternatively, use a descriptive name. query is too generic. You know what you’re dealing with, so make it clear (e.g. file_path). /usr/local/bin/tag --add paid {query} You’re not quoting {query}, which is where your issue lies. Spaces separate arguments—note how each instruction is separated by spaces—so if the value {query} expands to has spaces in it, they’ll be interpreted as different arguments. If the content of {query} were one two (note the space), unquoted {query} (what you have) would be two arguments (one and two); quoted {query} (i.e. "{query}" or '{query}') would be a single argument (one two), which is what you want. echo -n $query Same issue as above. Always quote your variables (unless you know what you’re doing and that you specifically do not want them quoted). The difference between double quotes (") and single quotes (') is that the latter takes everything literally while the former expands values. So echo -n "${query}" would expand to one two and echo -n '${query}' to ${query} (literal). Finally, use ${} instead of $. It’s clearer, and it will save you from situations where you need text next to your variable. Bash can understand ${query}three as one twothree, but $querythree tries to be read as a single variable and would fail. All together now (I’ve added readonly for added correctness, but it’s far from mandatory in this case): readonly file_path="${1}" /usr/local/bin/tag --add paid "${file_path}" echo -n "${file_path}"

@eluxmaxel @roccitman To bring youtube-dl up to date, try: "${HOME}/Library/Application Support/Alfred/Workflow Data/com.vitorgalvao.alfred._sharedresources/bin/youtube-dl" --update || /usr/local/bin/youtube-dl --update

Seems like it’s been fixed! Great news. Marking as solved.