deanishe

When you log into macOS, your session isn’t bootstrapped from a shell like it is on Linux (at least, it used to be), so none of the settings in your .bashrc or .zshrc are loaded. Those files are also explicitly for interactive sessions (when the shell is connected to a terminal emulator like Terminal.app or iTerm), so they also aren’t loaded when you run bash/zsh from any other application, like Alfred.

But what's the point? In the end, you can achieve the same result by setting PATH in your workflow, which is simpler for you and the user doesn't need to do anything. It's fairly straightforward to do. It's just a lot of work to do properly. You can't just grab favicons from Google or DuckDuckGo because regular favicons are too small for workflow icons. You need to fetch and parse the bookmark URL and possibly other files, too, to find a sufficiently large image.

There's nothing wrong with writing workflows with Node. It's distributing them as NPM packages instead of as .alfredworkflow files that is problematic. Workflows installed via NPM/Alfy don't sync between machines because they're not actually installed in Alfred's workflow directory. When Alfred upgrades a workflow, it preserves user settings (variables, keywords, hotkeys), but Alfy deletes them because it blindly overwrites everything. I guess it's easier for developers, but it just kinda sucks for users.

Probably worth mentioning that it's built as a Node package, not a workflow. A lot of people avoid such workflows because of all the issues the non-standard installation method causes.

That's correct. The cache and data directories are good places for machine-specific stuff. It's not really a good solution to this particular problem, however. Updating PATH to include both Homebrew bin directories is a lot more straightforward, and is in any case unavoidable if the program you're running wants to run other programs. It also seems likely that Alfred will add the native ability to adjust PATH for Homebrew.

Python's in much the same place as PHP on macOS right now. You either need Apple's developer tools or Homebrew to install Python 3. AFAIK, Ruby's still installed by default, but I wouldn't count on that lasting long, either.

What do you mean? That variable is set by Alfred.

Don't use Run NSAppleScript. It doesn't work very well. Use a regular Run Script with Language = /usr/bin/osascript (AppleScript).

You can only delete a Safari bookmark from Safari. There is no API for accessing Safari bookmarks. Any workflows or apps that show them are reading either data Safari exports or Safari's private data. Deleting those is pointless and very dangerous respectively.

That's not true for Vítor's original. Don't know what you've done with your modified version.

Just throwing this out there: How about 1–9 on the keypad work like hitting ↩ on the corresponding result, and using modifiers with the keypad works like hitting ↩ on the corresponding result with the same modifiers? So ⌥⌘3 (on the keypad) would be equivalent to hitting ⌥⌘↩ on the third result.

Now that you've pointed it out, it seems so obvious that the keypad should work that way.

Not in the way you mean, no. Alfred is a launcher, not an automation application. Its native ability to tell other applications to do things doesn't extend much beyond "open this". Alfred can fire keypresses at an application, but if you want to do anything more complex than that (moving the mouse, clicking), you will need to write a script to do it (which you can then run from Alfred). Or you can use Alfred to run a Keyboard Maestro macro. Unless you're doing something really simple, a userscript or other method of injecting JavaScript into the page would seem like a much better way of doing that to my mind. That way, you can use the actual APIs for adding keyboard shortcuts to a webpage. Getting software to use the human interface is usually difficult, slow and error prone.

Go into Alfred Preferences > Features > Universal Actions > General and uncheck ctrl under Show Actions. Does that fix the issue?

That’s largely pointless: where which XYZ works, you can just call XYZ directly. The most portable solution is to put export PATH=/opt/homebrew/bin:/usr/local/bin:$PATH at the top of your scripts. That will make sure Homebrew binaries are on PATH on Intel and Apple silicon.

That's not a good general solution because workflow variables are synced between machines. If one machine is Intel and the other Apple silicon, only one of them will work. Put export PATH=/opt/homebrew/bin:/usr/local/bin:$PATH at the top of your workflow scripts and then run programs by name (i.e. lpass, not /usr/local/bin/lpass).

Yes and no. It makes it so that you can call Homebrew binaries by name instead of their full path, but if the workflow is already using full paths (e.g. calling lpass as /usr/local/bin/lpass), you’ll need to edit it to just use executable names (e.g. lpass) in order for the workflow to run on both M1 and Intel Macs.

It's dumping a variable from within the PHP script to JSON, by the looks of it.

This is not a good solution because it will break with every Lastpass update. There's normally no reason to directly execute a program from the Homebrew Cellar. Executables are symlinked to $HOMEBREW_PREFIX/bin, which is where you’re supposed to run them from. Better to put export PATH=/opt/homebrew/bin:/usr/local/bin:$PATH at the top of the top-level scripts. Then the workflow should be able to find lpass on Intel and Apple machines.

We can't tell you anything useful based on a line of code from an unknown workflow. If it's somebody else's workflow, then please first see if there's an existing thread for it on the forum, and ask in there if there is. If not, then you'll need to post a link to the workflow.

It does for some people, but not for others. Indexing has always been temperamental. The primary issue with Google Drive File Stream is that it serves your drive from a random port. As a result, macOS thinks it's a different drive every time you restart GDFS, meaning you have to completely re-index it.

You need to install PHP. Apple removed it in Monterey. https://www.alfredapp.com/blog/releases/alfred-4-6-ready-for-macos-monterey/

Okay, the problem is that the workflow also calls php directly from bash scripts, which Alfred can’t fix so easily. Until we get an option to turn on Homebrew support, the only fix is to edit each of the Script Filters on the left-hand side from 0 down to time. In each of those Script Filters, at the top of each Script whose Language = /bin/bash, insert the line export PATH=/opt/homebrew/bin:/usr/local/bin:$PATH That should fix the workflow. I can’t test the fix because the workflow isn’t broken on my machine.

Which application are you talking about?

Read the thread. The solution is three posts above yours.