luckman212

Following up on this one, hoping in the future there's a way to programmatically trigger this reload function!

Thanks @Vero for looking at it. Yes these particular apps are in /Applications/Utilities/xxx and in actuality the "real" path may be /System/Volumes/Data/Applications/Utilities/xxx because of APFS obfuscation. Regardless, the "alfred:ignore" trick DOES work for me on files in /Applications proper. Just not this Utilities subfolder for some odd reason. That's the mysterious part, and why I thought it might belong in /Bugs.

Hi, macOS Monterey 12.0.1 Alfred 4.6.1 [1272] I have a problem with some apps like Adobe that litter the disk with dozens of useless "apps", cluttering my search results. If I type "creative" in Alfred for example, here's what it looks like: I'm trying to hide everything there except "Creative Cloud.app". The simplest way I know of is to add "alfred:ignore" to the Finder comments. This has worked for me in the past, but does not seem to work here. I've tried: quitting/relaunching Alfred using the "reload" keyword clicking the "Clear Application Cache" button in Settings > Advanced I know about adding the folder to Spotlight's ignore list, but I'd like to know why the alfred:ignore method isn't working. Any tips?

Excellent! Glad to hear.

@lamhoangtung I uploaded a new version of the workflow (1.0.1). Please give it a try!

@lamhoangtung You're running macOS 12 right?

It annoyed me that LiveText activated when I didn't want it (e.g. when trying to draw a marquee in Preview.app) so I came up with this quick little toggler for the feature. Only tested on macOS 12.0.1 on an M1 Mac Mini. Please report any problems! https://github.com/luckman212/alfredworkflows/blob/master/LiveText.alfredworkflow

Nice info @vitor — and you're right of course. I switched to a different theme and the dancing colon was gone. Always interesting to learn about obscure features like this. I suppose it'd be easy to change fonts by duplicating the theme in Alfred, but now that I know why this is happening it doesn't bother me anymore! Reminds me of this funny stand up comedy bit—can't remember who now (Ray Romano?) but goes something like..... "when you start getting older, you might notice a lump one day on one side and start panicking... until you feel the same lump on the other side and breathe a sigh of relief. Whew! It's symmetrical. It's supposed to be there!"

Oh wow. Didn't even think of testing Spotlight, but yeah— lo and behold, same thing. Strange one indeed. Thanks for looking, guess we'll see if macOS 12 changes anything.

macOS 11.5.2 Alfred 4.5.1.1256

Saw this today, while starting to type a time into Alfred.... made a short recording Keep your eye on that : colon ... https://user-images.githubusercontent.com/1992842/129944232-f1a889a9-5e9e-4e17-a694-f6d50c711a5f.mp4

@Andrew Thanks. I think this might have been a problem with the metadata in Setapp itself- it updated a couple of days ago, and after doing a reload in Alfred, the problem has gone away. ¯\_(ツ)_/¯

@Andrew sure, just tried that (twice in fact). Did not help in this case. Also saw a new beta was out (1253) so I gave that a whirl. but no change.

Oh I've run into this a number of times too. Would be so useful.

I'm having a problem on ONE of my Macs (M1 Mini) where results are showing up that I don't want (from ~/Library subfolders, see example screenshot). I've tried rebuilding Alfred's metadata cache but it didn't resolve this. Strangely, on my Intel Macbook Air this problem doesn't manifest. Both systems are running the same version of MacOS (11.5.1) and Alfred (4.5.1252) and are sharing synced preferences.

I was surprised this wasn't possible, but today I wanted to drag 2 items I had collected in Alfred's buffer to another app that can receive file drops. I found out that it only seems to allow dragging 1 file at a time from the buffer area. Am I missing something or is there any way to do this? Yes I know about "actioning all items" to send buffer contents to a workflow but I specifically need to drag them in this case. (Alfred 4.5 b1252 by the way...)

This is great. Glad to see so much discussion and careful thought around this issue. Thanks @deanishe for your explanation of the subprocess / PATH issue. And thanks to @vitor and of course @Andrew as well. I agree with the concept of a per-workflow: [x] Enable Homebrew support checkbox that sets PATH and HOMEBREW_PREFIX . That seems like a really low-impact way to provide this functionality without affecting anything for existing users or people who chose not to use it. Actually it doesn't ignore it—I've run into trouble once or twice by overriding PATH and forgetting to include a necessary dir. Example: (Script: echo $PATH )

Not sure what you mean here... if Alfred exports HOMEBREW_PREFIX then any programs forked from it should inherit that value, no? Maybe I'm misunderstanding.

@vitor I like the idea of using brew shellenv to get the values. But, isn't there a chicken vs. egg problem? How to know which brew to invoke without first having the prefix? I suppose it could just go with the defaults as mentioned farther up, or... How about a field under Advanced that reads: Path to `brew` command: [______________________] ( Default for this system: /opt/homebrew/bin/ ) If users simply do nothing, then it uses the default. But if some lunatic has their brew at /users/john/stuff/brew, then they can simply fill that into the field.

Yes that would definitely solve most of the cases! I suggest the variable be $HOMEBREW_PREFIX however, just to align with what they currently use [https://docs.brew.sh/Manpage#shellenv]. Not anywhere that I can see, but that'd probably be a good addition. Thanks @deanishe

Just want to clarify—I never was asking for a "global PATH" setting. Just a way to set global variables (e.g. $MY_COOL_API_KEY ). There could (should) even be a warning about not setting a global PATH variable right in the dialog box...

I think we're on the same side here. My suggestion would make it precisely so the workflow could explicitly target the right version of a tool, instead of leaving it up to whatever the user has in their $PATH which could be incorrect. Hypothetical example: I create a workflow that requires the jq binary, which is available in Homebrew, but can also be installed in other ways. My workflow tests for the existence of jq and throws an error if it's not found, prompting the user to put it in their $PATH . One way to do this would be if [[ ! $(command -v jq) ]]; then ..throw error.. fi A few possible solutions would be: Method #1 Bundle a copy of jq with your workflow (not sure if licenses will allow this) and hardcode your scripts to use that version with dot-slash: #!/usr/bin/env bash blah blah ./jq '.foo[] | .bar' blah Drawbacks: - Might run into problems with license - Which version of the tool to include? Intel? ARM? What if there's no universal binary? Now we need 2 versions of the tool, and extra code like if [[ $(arch) == "i386" ]]; then foo... etc. - Tool can't be shared among workflows, leads to redundancy and mismatched versions. Method #2 Ask the user or have steps in the workflow itself that set the environment variables correctly. E.g. prompt them to set the $PATH or some var called $JQ_PATH in the workflow itself. And then in your scripts, have someting like this #!/usr/bin/env bash if [[ -z $JQ_PATH ]]; then ..prompt user to set JQ_PATH.. exit 1 fi if [[ ! -x $JQ_PATH ]]; then ..tell user they have specified an invalid binary path.. exit 1 fi blah blah | $JQ_PATH '{ foo: bar }' Drawbacks: - May be frustrating and error-prone for the user to do these steps - Very little guarantee that they will install the tool correctly - If workflow is sync'ed across multiple machines, no guarantee all machines will have the same architecture, PATH etc. Method #3 Use Homebrew, MacPorts etc. This is in my opinion a better option. It provides a consistent way to share tools across machines and workflows, and a reasonable guarantee that those tools will be up-to-date and in a consistent state. It would allow the workflow-embedded scripts to simply reference unversioned, unqualified versions of the tools, e.g. jq '.foo' or even better $HOMEBREW_PREFIX/bin/jq '.foo' . This would work across machines & architectures without any fuss. All that would be required would be a simple global environment variable: $HOMEBREW_PREFIX which could be defined directly in Alfred, or via ~/.bashrc or any other env file if the $BASH_ENV var is set. Drawbacks: - requires one-time setup (user must put in their Homebrew path once in the global vars area. This could be made easier if it had a fallback value (/usr/local/bin on Intel and /opt/homebrew on arm64) since 99.5% of people would use the defaults. Advantages: - One or two clicks is all it takes to enable this for the entire set of workflows - Simple to override (workflows can still hardcode paths, embed their own versions of tools, or override PATH variable etc) as before - Simple to change/update (e.g. if switching shells, moving from Homebrew to MacPorts, NIX etc. (again, one place to go instead of hunting through dozens of individual workflows) - Cross platform, well-suited for users who use multiple machines and sync workflows I'm sure there are other methods and ways, these are just some that come to mind. I'd like to know @Andrew's thoughts too if he cares to read.

The whole point of this is so the users DON'T have to faff around with PATH or any other vars to make scripts that work in Alfred the same way they do "outside of Alfred". This setting would be tucked away somewhere (along with the myriad other settings in Alfred) and default to {null} so it would not do anything until & unless needed. Not sure why it should cause any additional support requests. I thought about overloading PATH like this too. But, we'd be back to having to manually set the PATH variable for each individual workflow, which is what I'm trying to avoid in the first place. Also, on the ARM machine /usr/local/bin also exists. So there's potential for the wrong binary to be executed. $HOMEBREW_PREFIX/bin/my_prog is faster (no need to traverse the whole path) and also predictable.

Well here's the low hanging fruit @deanishe ... I just got my first M1 Mac (a Mini), and am now syncing my Alfred configs between it and my trusty old Intel MacBook Air. I use Homebrew on both, and a handful of my workflows require commands from it. I learned the hard way that on arm64, Homebrew likes to live in /opt/homebrew -- vs /usr/local/bin on x86. So I can't hardcode paths... and $PATH must be different on each Mac. This was my first task: unwinding all those hardcoded /usr/local/bin/foo... references. The recommended best practice is to export a $HOMEBREW_PREFIX env var and add it to your PATH. This is done in my ~/.bashrc currently. This also ensures that the standard shebang of #!/usr/bin/env bash results in Bash5 instead of the ancient Bash3 that is rotting away in the default OS. This all works great in a normal login shell, but not in Alfred. I found the cleanest solution to be setting $BASH_ENV which causes my .bashrc to be sourced inside Alfred. For me, it would be very useful to be able to set this globally to apply it to all scripts -- I had to do a lot of hunting and pecking through workflows to figure out where it was needed and why certain things were broken. If I ever need to source a different file (e.g. if I switch to zsh) it would be a chore to update all those workflows again.

Alfred 4.5 build 1249 macOS 11.5 When Alfred executes Bash scripts with the standard shebang of `#!/usr/bin/env bash`, it runs a non-login, non-interactive shell (`/bin/bash foo.sh`). This means that ~/.bashrc, ~/.bash_profile, /etc/bashrc etc are not sourced. This makes it difficult to set certain environment parameters, notably $PATH, $HOMEBREW_PREFIX etc. I found that setting $BASH_ENV to ~/.bashrc is a workaround. As per the Bash manpage, that var causes bash to source the specified file on noninteractive shells. TL;DR— is there any way to globally set a variable to apply to all workflows? I can definitely set it for each individual wf, but this would be a nice feature...