deanishe

That's not possible. The workflow has no way of knowing which view you came from, nor can you tell Alfred to navigate to an arbitrary view. The closest you can get is re-opening Alfred and simulating a ↑ keypress to go to the previous query.

You can, but you need to turn on "Use F1, F2 etc. keys as standard function keys" in System Preferences > Keyboard > Keyboard. If that's off (the default, IIRC), then pressing the F4 key will run the special function printed on it, and you actually need to press Fn+F4 for F4.

Search for Finder in Alfred, then use the Recent Documents… Universal Action on it.

Not really, no. Alfred doesn't decide what happens when it runs an application, the application does. What happens when you launch an app in Alfred is just what happens when you launch that app on macOS. I guess it would be technically possible for Alfred to activate the application if it's already running instead of launching it (like clicking on a Dock icon). It's also simple to implement as a Hotkey.

suffixes=(stock graphics "and so on") for s in $suffixes; do mkdir -vp "${1}/${1:t}_${s}" >&2 done # pass root directory path to next action echo -n "$1"

Connect your File Action to this Run Script (Language = /bin/zsh): # for directory X/Y/Z, create X/Y/Z/Z_1 through X/Y/Z/Z_5 for n in $( seq 1 5 ); do mkdir -vp "${1}/${1:t}_${n}" >&2 done # pass root directory path to next action echo -n "$1"

I can see that, but it seems to me that you're disregarding the effort it takes to implement these things again. It's never just a question of the value a feature would bring, but the opportunity cost of other stuff that gets dropped or pushed back as a result. I bet it dwarfs the number of users bothered by the lack of theming on the "update available" text… You really think this is worth putting some other feature aside for? I mean, can you imagine a situation where this would be anywhere near the top of your list of things you'd want Andrew to spend his limited time on? I dunno. I just don't really understand why we're still having this conversation when you know there's only one Alfred developer.

Essentially, no. I dunno whether Alfred can stop macOS showing that dialog (it's being triggered by the Python binary) but seamlessly swapping in an alternate interpreter – like Alfred does with PHP – won't work because many to most Python 2 workflows aren't compatible with Python 3, and there are no other Python 2 interpreters available to swap in (it's dead, Jim). Something does need to be done about the /usr/bin/python interpreter option for scripts. Removal, probably, at least for new scripts. I’m not sure if replacing it with /usr/bin/python3 is a good idea because that’s a stub binary that asks you to install the macOS Developer Tools if you haven’t already. I suspect Apple's plan is to remove all interpreters from macOS except for their own (i.e. AppleScript and JavaScript), and whatever we do should be with the expectation of being reliant on Homebrew within a few years.

No, that's the expected behaviour. You don't want Quicklook popping up when you're holding ⇧ to type a capital letter.

I wouldn't include that in the workflow script: it's very slow.

Do shortcuts for other applications work? Is it only Alfred that's affected?

By not using pyenv, tbh. macOS comes with Python 2, and Apple provides Python 3 as part of their official dev tools. Homebrew also includes Python 3. These are all much better choices because they aren't in some random location in your home directory. If you build your workflow with pyenv, it’s unusable on any other machine without a lot of messing around. PATH=/opt/homebrew/bin:/usr/local/bin:$PATH python3 is a lot more user friendly. Don’t install workflow deps, bundle them with the workflow: python3 -m pip install --target /path/to/workflow clipboard As above, it means less messing around to get the workflow running on another machine. ⌘Q is Quit, not Copy. ⌘V is paste. Sourcing ~/.zshrc in a workflow is bad form. It isn't loaded automatically because it's for configuration options for interactive shells. Sourcing it here is breaking the rules, and likely to cause problems further down the road. Similarly, initialising pyenv and activating a virtualenv in a workflow is something to avoid because it's very slow (which sourcing ~/.zshrc often is, too). It won't kill you in a Run Script, but you'll never get decent performance from a Script Filter doing that. If you're going to make your workflows non-portable by basing them on pyenv, I reckon you might as well just hardcode the path to the virtualenv and save all the pyenv overhead.

Do you have Homebrew installed? You need to install PHP via Homebrew. The workflow doesn't work because Apple has removed PHP from macOS. If you install PHP via Homebrew, Alfred should find it and run the workflow with that instead.

Hi @chumido, welcome to the forum. Update Alfred. This is fixed in version 4.6, released 10 days ago.

Unless you're doing something weird like running your workflows with pyenv, when you update Python, the new version will replace the old one and the executable will be in exactly the same place. Well, for one thing, the other solutions don't introduce external dependencies, and for another, they're how you're actually supposed to solve this problem. What you are doing is basically misusing bash. The entire purpose of ~/.bashrc is to contain stuff that's only loaded in interactive shells – that's why bash isn't automatically loading it in Alfred to begin with – and by breaking that rule, you're setting yourself up for problems further down the road. That's not a good solution, either, seeing as Python 2 is no longer in development. Only a matter of time before that breaks. There is no obviously best solution for writing and sharing Python workflows at the moment. All the same, there's no reason to deliberately make one unshareable by sourcing your ~/.bashrc.

Instead, you've made your workflow dependent on your shell configuration, which is a much worse solution. There is a good reason your shell config files aren't loaded in non-interactive shells. Now you have to worry about your workflow when editing your shell config. And like Vítor says, your workflow won't work on another machine that doesn't have a similarly-configured shell.

That’s what I was wondering about. Have tabs, bookmarks and history, and only set UIDs on the first non-empty group. That should keep the other groups below them? I guess I'll have to switch to using URLs as UIDs instead of Firefox's own UIDs. All URL handling is done via scripts, so a user could add that behaviour themselves.

It's more complicated than that. Shells load different startup files depending on whether they're running interactively (i.e. in a terminal emulator) or not (i.e. in Alfred). The normal configuration is that all your customisations are not loaded in a non-interactive shell. If you want something in /usr/local/bin to be run, you either need to call it by its full path (i.e. /usr/local/bin/python3 ..., not just python3 ..), or to put export PATH=/usr/local/bin:$PATH at the top of your shell script.

This has been requested before, and I totally see value in the feature. The problem is, I haven't figured out a way to do it that isn't crap in some important way. This is the tricky bit. One of Alfred's most important features is its "knowledge" – its ability to learn from your behaviour, so you can train it to associate, say, the query "jt" with your "Jira – Tickets" tab. The only way to enforce tabs > bookmarks > history ordering is for the workflow to disable Alfred's knowledge, which I am very reluctant to do. The obvious alternative – only show bookmarks if no tabs match; only show history if no bookmarks match, either – kinda sucks. I mean, imagine trying to get your Google Mail bookmark to show up when you've got 15 Google searches open in tabs. If I (or anyone else) can think of a decent way to implement it, I'm certainly open to doing it.

That's a Brave bug, tbh. It's the application's job to manage its own windows and make sure the right one is visible. It's also not something a workflow can easily work around.

Why? What's the use case? What do you think the typical Alfred user is going to do with the feature? To my mind, this sounds very niche. And there are already applications that can do this.

Yeah, this keeps biting me, too, and it's rather irritating. The Universal Action list just doesn't behave like Alfred is supposed to (in my mind). I'm not sure there's a lot of value in manual ordering. Re-ordering results based on your usage is kinda Alfred's thing, and it makes a manually-ordered list somewhat pointless. To my mind, the issue is rather that the algorithm Alfred currently uses to sort Actions is different to the way normal search works. We all train ourselves to consistently use the same search terms for the same items, and in return Alfred consistently ensures that the same item is always the top result for a given query. But the Actions list deviates from that behaviour, making it inherently somewhat tricky to use.

Short answer: no. There's no option or API to tell Finder to open folders in a new tab. The only way to do it is to blindly fire simulated keypresses at Finder, wait a bit and tell Finder to navigate to the folder, hoping a new tab has opened in that time. It's very unlikely that Andrew would add that behaviour to Alfred because it's so hacky and unreliable.

I don't know if anything has changed, but I'm certain Alfred doesn't and never has launched detached workflow processes. I believe Alfred uses NSTask to run workflows, and that doesn't even support anything fancy. If LS is now detecting Chrome as a subprocess of Alfred when it wasn't before, it seems far more likely that something has changed in Chrome or LS (or the macOS APIs it uses). I don’t have Big Sur or LS 5, but the “new” behaviour you describe is how previous versions of Little Snitch have worked for many years. If you run curl in a shell, LS asks about “iTerm via curl”. Similarly, it has always asked about “Alfred via <workflow-binary>”. That is exactly the behaviour I would expect if Chrome is really running in the subprocess, not handing off to an already-running instance.

The best solution is to launch Alfred when the volume is mounted. Try the Launch Agent I posted here: