luckman212

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...

Wish I had the chops for that @deanishe but it's likely above my pay grade. Maybe I'll try. Do you think in general it's a good idea to switch my configuration to a SQLite db instead of the current plaintext json? My reasons for wanting to do this are mainly: reduce chances of error in data entry ability to query ahead of time to constrain results vs doing the filtering after (although there's a tradeoff of course since once the results are cached, Alfreds builtin filtering is probably faster) ability to quickly sort entries by the various fields currently the config.json data looks like this (sample): [ { "title": "Mnemonics snips folder", "desc": "open folder of snips for this workflow", "keywords": [ "mnemonics","snippets","cfg","config" ], "type": "file", "icon": "f-atom.png", "object": "./snips/", "bundleid": "com.apple.finder", "contexts": [ "com.runningwithcrayons.Alfred-Preferences" ] }, { "title": "Search for executables in Terminal", "keywords": [ "command","find","binaries","perm","perms","type","111" ], "type": "copy", "icon": "terminal.png", "object": "find . -type f -perm 111 ! -name \"*.*\"" }, { "title": "Create symlinks", "desc": "ln -s[fiv] /path/to/file [/path/to/symlink] (default=current dir)", "keywords": [ "soft","hard","command","ln","alias","syntax","link" ], "type": "copy", "icon": "terminal.png", "object": "ln -s /path/to/file /path/to/symlink", "url": "x-man-page://ln" }, ...

Thanks @deanishe and @Mr Pennyworth for the advice and knowledge. Figured I'd share what I ended up with so far, in case it's useful. I'd also welcome any advice on whether this code is utter garbage or wildly unsafe etc, as I am not a Swift developer by any stretch. The below produces a small binary which outputs 3 fields (tab-separated): bundle_id, localized app name, and path. There's some error checking in there but it was a bit of trial and error, so not sure it's correct. I use this in my script filter to filter the results by bundle ID of the frontmost app, and use the App Name and Path in the JSON to prefix the items e.g. "Google Chrome: foo bar" and grab the native app icon to distinguish those results. The workflow is called "Mnemonics" and it's kind of my own TLDR system to help me remember how to do little things e.g. How do I set a variable to the contents of a heredoc in bash? or What's the keyboard shortcut for opening the Artboard in Adobe Illustrator?. I will probably publish it soon. Just need to switch the filter from Bash to Python (to remove the dependency on jq) and switch the config file from plaintxt JSON to SQLite... frontmost.swift (compile with `swiftc frontmost.swift`) import AppKit final class StandardErrorOutputStream: TextOutputStream { func write(_ string: String) { FileHandle.standardError.write(Data(string.utf8)) } } enum frontmostError: Error { case bundleid case path } do { let frontApp: NSRunningApplication = NSWorkspace.shared.frontmostApplication! guard let bundleid: String = frontApp.bundleIdentifier else { throw frontmostError.bundleid } guard let path: String = frontApp.bundleURL?.path else { throw frontmostError.path } let name: String = frontApp.localizedName ?? bundleid print(bundleid, name, path, separator:"\t", terminator:"\n") } catch { var outputStream = StandardErrorOutputStream() print("error: \(error)", to: &outputStream) exit(EXIT_FAILURE) } Bash script filter (partial) IFS=$'\t' read -r bundle_id app_name app_path < <(/usr/local/bin/frontmost) [ -n "$bundle_id" ] || exit /usr/local/bin/jq <config.json \ --arg b "$bundle_id" \ --arg n "$app_name" \ --arg p "$app_path" \ '{ items: [ .[] | select(.contexts != null) | .contexts as $c | select($b | IN($c[])) | ...

@Mr Pennyworth that's cool - how would I use that to get the variable into the script filter? I'd call out to that "./frontmost" executable from inside my Python script? edit: I compiled your swift binary and it is indeed very fast. I got it to work using this #!/usr/bin/python import os try: cmd = '/usr/local/bin/frontmost' bundle_id = os.popen(cmd).read() except: exit(1) ...rest of the workflow I'm sure there are much better/safer ways to do this using e.g. subprocess()... is this the right path to take?

I'm looking for an efficient way to get the bundle ID of the frontmost app into a workflow variable to be used in a script filter. (basically want the script filter to display context-specific results based on the frontmost app) I tried searching for a way to do this but came up short. anyone got a tip? I know I can get this info using e.g. Python... but that seems a bit slow/inefficient #!/usr/bin/python from AppKit import NSWorkspace try: bundle_id = NSWorkspace.sharedWorkspace().frontmostApplication().bundleIdentifier() except: print('unknown') exit(1) if bundle_id: print(bundle_id)

Hi @Andrew wanted to ask if you'd consider adding truncate and/or range transforms to Alfred? This could be useful e.g. in the Snippets feature, if you want to grab the first 50 chars of a clipboard that could contain 1000s of chars: {clipboard:truncate(50)} or in a similar vein, a range command like {clipboard:range(10..50)} to grab chars 10->50 https://www.alfredapp.com/help/workflows/advanced/placeholders/#modifiers

Thanks @Andrew ! Sounds great.

I want to use <shift> in a mods: {...} section to toggle the subtitle to show some other data. The problem frequently manifests itself when tapping shift twice in a row too quickly. No, all results don't have x-man-page:// — they are all sorts of different things, URLs, file paths, strings of text, etc.

Thanks @deanishe that's what I thought... Would be a nice feature to have. I guess the poor man's workaround is to pass your data via another variable and just set arg to null, eh? eg ... title: "no quicklook here!", arg: null, variables: { realarg: "x-man-page://ln" }

It does not seem possible to DISABLE quicklookurl for a script filter, either globally or for an individual JSON object/entry. I tried setting quicklookurl to null, as well as "" — but neither worked. Is this possible at all?

Yes @godbout opening Xcode is another reliable way to trigger this for me too. @Andrew it's most noticable on a cold start (after a fresh boot) of a "large" app like Xcode or Microsoft Excel. Another app that I can definitely repeatedly trigger this with is Setapp. I know this is a bit low-tech but I couldn't figure out another way to capture this, so I recorded a couple of seconds with my phone, so you can get an idea of what this looks like... Setapp... https://user-images.githubusercontent.com/1992842/117302537-bce67e80-ae49-11eb-859a-13400dbecc57.mov Excel... (around 9s is where the hang starts - Excel dock icon was still bouncing...) https://user-images.githubusercontent.com/1992842/117302524-ba842480-ae49-11eb-9883-fa85f9ab5adb.mov

@Vero I know what you mean about newlines being treated differently by different OS'es e.g. Mac vs Windows. But if we confine it to just macOS (since we're only talking Alfred here) the definition is pretty clear: it should be 1 + the count of the "0A" hex bytes in a block of text (excluding a final trailing newline if there is one). I'm looking for the same output that would be shown by this bash script: wc -l <<< "${clipboard%$'\n'}" Not sure what page width has to do with it? I'll give you a simple use case (this happened to me yesterday which is what prompted me to post this request). Let's say someone sends you a list of email addresses, and you've copied them to the clipboard. You want to know how many email addresses you have. It would be great if I could just flip open Alfred's clipboard history and see it there without having to paste this into Sublime Text to see the linecount etc.

@giovanni Thanks but that's not the same. Having it display in the clipboard viewer gives you the ability to quickly flip through history items and see the count, vs having to place items in the clipboard first and then run a workflow.

Currently, the clipboard viewer (very helpfully) shows the word and character counts: Just a suggestion: it would be useful to also display the line count here, if possible!

Just wanted to post a little note on this: I discovered an option I wasn't aware of today in Alfred's Appearance > Options area: I thought maybe this would have some effect on this problem, but alas I tested it and they are both affected by the thread lock. I'm now using Alfred v4.3.4.1229

Hi @Andrew - I just tested & the menubar hat goes zombie as well (other menubar icons are ok). So whatever's going on with this thread locking is across the board.

I just tested it after changing the hotkey to ⌥A — same issue.

Yes, other hotkeys e.g. ⌘-space or F8 (which toggles my crosshairs from PixelSnap) continue to work fine during these unresponsive times. So it's not F-keys. It's only Alfred that gets hung up for some reason.

macOS 11.2.2 Alfred 4.3.2.1221 When hitting my main Alfred hotkey (F11) his window usually appears instantly. But, I've noticed that during certain conditions, such as shortly after launching a slow-to-open app from the Dock (Excel, Photoshop, etc) the Alfred window does not appear. Instead, it seems to hang until the foreground app is in the "ready" state. (Not sure technically what this is called, but essentially it's ready to receive input - mouse clicks, key events, etc). This can also happen if the foreground app gets busy, doing some long running task etc. Funny thing is, if I click to another app e.g. Finder and then hit the hotkey, Alfred appears immediately. Just wondering if there's any way to change this behavior so that the hotkey stays more responsive even during these busy times.

@gingerbeardman Hey 👋 Happy Friday! I wasn't referring to your workflow actually. I was talking about Red Sweater's Usable Keychain Scripting (download).

By Jove you've done it! Thanks again for this 🎉 P.S. to anyone else who happened to download the test workflow above, I noticed a bug in it this morning- $RANDOM is 16-bit only (0-32767) so the jibberish output only contains words beginning with the letters {a,b,c}. Pretty boring. Newer versions of Bash support $SRANDOM which is 32-bit, so changing the shebang to #!/usr/local/bin/bash and RANDOM to SRANDOM will "fix" it. Also, swapping in gnu-sed for the built in macOS sed speeds up the loop by a factor of 2 for me. Here's an updated version in case anyone cares: LargeType Odd Wrapping_v0.0.2.alfredworkflow (use brew install bash gsed to satisfy the requirements...)