Jump to content

luckman212

Member
  • Posts

    191
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by luckman212

  1. 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!"
  2. 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.
  3. 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
  4. @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. ¯\_(ツ)_/¯
  5. @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.
  6. Oh I've run into this a number of times too. Would be so useful.
  7. 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.
  8. 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...)
  9. 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 )
  10. 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.
  11. @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.
  12. 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
  13. 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...
  14. 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.
  15. 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.
  16. 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.
  17. 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...
  18. 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" }, ...
  19. 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[])) | ...
  20. @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?
  21. 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)
  22. 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
  23. 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.
×
×
  • Create New...