deanishe

There's a very good reason for that. Namely, it breaks your operating system. The people saying that know what they're talking about. If you really want to break your system, by all means go ahead, but please don't go telling other people to do the same silly thing. Homebrew Python does not come with the same libraries installed as the system Python, so there's a very good chance you'll break other software. Your changes will also be overwritten when you update the OS. If you want to use a different Python, edit the workflow instead of — quite literally — breaking your OS X installation. It's absolutely trivial to fix. All you have to do is open the Script Filter in the workflow and change "python bookmarks.py…" to "/usr/local/bin/python bookmarks.py…" If you'd just asked, anyone who knows anything about Python could have told you that. Instead, you go and start overwriting parts of your operating system and then tell other people to do the same thing. Not the smartest move, tbh. If I were you, I'd go an find my Snow Leopard install media and repair the system. There's a fair chance you broke something else "fixing" the workflow.

On a somewhat related note, can you add the current workflow keyword to Alfred's environmental variables? That would be a huge help for workflows that want to call themselves. I know you can call an External Trigger instead, but you know I really don't like that mode, and randomly (from a user's perspective) switching modes because a workflow's implementation requires it to call itself is bad UX.

Or drag as fast as you want sideways.

I know about sips, so there's likely a reason I didn't use it. Perhaps I couldn't get the transparency to work?

I tried that, and it doesn't work. I tried long ago to set up a File Filter for ~/Library/Logs. Can search the files just fine in Finder, but Alfred can't "see" most of them, "show system files" or no. I can't recall right now whether mdfind worked or not.

I'll have a go, but it's more of a complete rewrite than plugging it in. Do you keep your GIFs in ~/Dropbox/Public/gifs too?

It seems Alfred doesn't get along with most folders in ~/Library, neither in File Filters nor in its default results.

FWIW, when it runs your workflow, Alfred sets the alfred_version environment variable to its own version number. You could grab the first character of that and insert it in your paths to support both v2 and v3. Be warned, however, that if you edit a workflow in Alfred 3, it will no longer run in Alfred 2, regardless of whether you use any Alfred 3-specific features or not.

Manipulating windows isn't something that Alfred has explicit support for. It can be done, all the same, but only by implementing what you want in AppleScript and then running it with Alfred. It'd be a lot easier to do with an application whose purpose is arranging windows.

I'm not a designer. You're both evil and should feel evil With that out of the way, here is a module from one of my workflows for generating Alfred-sized thumbnails while preserving aspect ratio. It's not particularly standalone, however. It depends on GraphicsMagick (via Homebrew) and uses Alfred-Workflow to keep the workflow snappy (thumbnails are generated in the background). You might be able to make use of the GraphicsMagick command or the module itself. If you need help integrating it with another workflow, just ask.

Moving to Workflow Help & Questions forum

It also bears mentioning that you only need root privileges (and therefore your password) to start servers like Apache and MySQL because they run on privileged ports (<1024) and/or under special, locked-down accounts. If you're not using your computer as an actual "production" server, you don't need these features. For local development, it's much easier to run them from your normal user account (run Apache on port 8080, for example). That way, you also don't have to mess about with sudo and root permissions to edit configuration files.

Terminal displaying your password isn't the only downside: it's also sitting around in plaintext. Not a good idea. The AppleScript method is way better, imo. OS X pops up its standard "Enter your password" dialog, i.e. it uses a GUI, not a shell (that also displays your password). If you don't want to be asked for your password, you should edit the sudoers file. It's not that complicated, and your password isn't sitting around in plaintext. You can also restrict it to specific commands/scripts/programs: username ALL=(ALL:ALL) NOPASSWD: /path/to/command (Obviously, replace username with your username and /path/to/command with, well, the path to the script/program)

Sounds like a List Filter would be a good fit for that (assuming you're using Alfred 3).

Alfred's cache only contains applications and preference panes. Resetting it has no effect on other kinds of results. Alfred relies on the same index as Spotlight for everything else. Afraid I can't help you with the actual issue

I don't think the Packal updater works at the moment. Not sure if it doesn't get along with El Cap/Sierra or Alfred 3. You could try my Packal workflow search workflow, which is, frankly, too dumb to break… It can't update your workflows for you, but packal status will show you which of your workflows are out of date, and actioning a result will take you to that workflow's page from whence you can grab the newer version. Nowhere near as nice as the official Packal updater, but better than checking everything by hand…

Heh, you're right. I'd forgotten what my solution was, and it is nicely forward compatible. (FWIW, I think Andrew is looking into just using "Alfred" as the app name in AppleScript.) I started hours ago…

I think someone smarter than me figured out how to do it with AppleScript. I can't remember exactly, but it involves asking System Events if there's a program named "Alfred X" running

A super-quick win on Packal might be changing the subtitle on workflow pages from "An Alfred 2 Workflow" to just "An Alfred Workflow".

I figured you must be talking to Shawn. OTOH, both of use have always had our locations right <----- here I'm also not German. Just lived here my entire adult life. Although now my stupid countrymen are leaving the EU, I'm probably going to apply to become a German. Best chance I've got of being World Champion…

Who now? Shawn or me?

Hey Shawn! How's tricks? We've missed ya.

Yeah. That only applies to Linux file systems, where filenames are bytes. On HFS+, filenames are all UTF-8 (normalised to NFD, nearly). Both using JSON and setting multiple variables, which I previously mentioned, would work. It is perfectly possible as I described. Just clunky and error prone compared to a native File Action…

Dumping the index metadata says that "di" is set as the comment, but the index search isn't responding to "di" as a query on the comment. All appearances point to a discrepancy between what the OS X/macOS metadata index says and what it does.

To save multiple files (or multiple anything else) to a workflow variable, you'll need to encode them as JSON (or some other string) first, so they can be passed as one variable. JSON is a good fit, or you can join the paths with colons, like PATH, or join them with newlines etc. Alternatively, you could set a bunch of variables, e.g. PATH_1, PATH_2, PATH_3 etc. That would probably mean implementing your own folder search for the destination, however. Alternatively, you could save the paths to a temporary cache file, then add another File Action for "My Workflow Target" which loads the paths from the cache and performs whatever action on them. The issue there is that it's hard-to-impossible to enforce that your "My Workflow Target" File Action is called with freshly-selected paths. Best you can probably do is to delete the cache file if it's too old (or ask for confirmation of the paths).