luckman212

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.