Jump to content

Run Command — Run commands using your shell configuration

Recommended Posts


Run shell commands without opening a terminal via the cmd keyword. Your shell’s configuration files will be loaded, making your custom aliases, functions, and more available to the environment. Commands execute relative to the frontmost Finder window to allow quick changes on the current working folder. Exit status is shown as a notification and output in a Text View.


  • ↩ Run the command.
  • ⌘↩ Run command but do not open output in Text View.
  • ⌥↩ Show command history to rerun a command.

Use the Universal Action to send files and text as arguments to a command. If the placeholder from the Workflow’s Configuration is present in the text, it will be replaced with your arguments, otherwise they are appended to the end.



The same modifiers apply. Separate command histories are created for commands ran with the Keyword or the Universal Action.


  • ↩ Run command.
  • ⌘↩ Delete all command histories and saved outputs.
  • ⌘Y (or tap ⇧) Quick Look saved output.

⤓ Install on the Alfred Gallery | Source

Link to comment

This is a file action to run a terminal command on selected files/directories.


Just use Alfred to pick what you want to run a command on and pick “RunCommand”, as the action. Alfred’s main window will appear and you simply type the command you want.


Extra notes

The workflow actually consists of two parts. The first one is the only one you’ll want to call explicitly; “RunCommand”, which calls “runcommand”. I’d prefer to have done this a bit differently, but Alfred doesn’t allow connections to the “File Action” trigger that’d allow to do it (at least not without adding a lot more).









I don’t care, do whatever you want with this. If you make any changes that could benefit the script, I’d certainly appreciate if you’d share them (perhaps I could incorporate them), but it’s not at all required.


Nice. You might want to change to xargs to support spaces.


So, your perl becomes this: echo "{query}" | perl -pe 's/[\t\n]/\0/g' > file_list

And your bash becomes this: cat file_list | xargs -0 {query}

Link to comment


Previously this would get your command and run it with the files as arguments at the end. You can now pick where the file arguments should go in the command (this is optional), by using “{}” (original post updated to reflect this information).


Great workflow!
I personally added a "Large Type" at the end of the runcommand, otherwise I had no idea how the command ended

Thank you. It now outputs a notification by default, with the output of the command. This way it can show a notification when you ask (when using “‐v”, for example), and not when you don’t.

Edited by Vítor
Link to comment
  • 2 weeks later...
  • 3 weeks later...

Could you expand this for using PathFinder? I am trying to get the workflows I use a lot moved to workable with that app.


There’s no reason it shouldn’t work with PathFinder — this does not depend on Finder in any way, and it works for me (I’m also a PathFinder user), what command are you trying to run?

Link to comment

I am trying to use it with ImageMagick convert routine, but nothing ever happens. I assumed it was the use of PathFinder because so many do not work with it. Upon examining the workflow more, I see that it doesn't use Finder. I can not figure out why it will not work for me. Any idea?

Link to comment

I am trying to use it with ImageMagick convert routine, but nothing ever happens. I assumed it was the use of PathFinder because so many do not work with it. Upon examining the workflow more, I see that it doesn't use Finder. I can not figure out why it will not work for me. Any idea?


Yes, I think I might know what’s wrong. Did you install ImageMagick via homebrew? Alfred “Run Script” doesn’t read you shell’s profile, so that’s probably the issue. Two very quick fixes. You can simply run (in the terminal)

ln -s /usr/local/bin/convert /usr/bin

which works, but then you'd have to do that for every command you want to use. Or you could open the workflow, and on the last “Run Script” (the one that connects to the notification), you add at the top of the code something like

export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
Edited by Vítor
Link to comment
  • 1 month later...
  • 2 months later...
  • 5 months later...
  • 1 month later...
  • 1 month later...

I can show you how to do it, but I won’t change it officially without a strong reason. I’ve picked {} because it’s unlikely you’ll need to type it on a command, or by mistake; kk, on the other hand, could easily break. Why would you like a different keyword?

To change it, open the workflow’s directory, open the runcommand file in a text editor, and change the 25th line accordingly. Where it says xargs -0 -J {}, change it to xargs -0 -J kk.

Link to comment
  • 4 months later...

I don't understand the complexity of RunCommand


Why can't you just have a /bin/bash script block whose first line contains {query}


Then if you have a keyword 't' you can just type things like


t date





t ls /Applications | grep -i photo



Seems to work fine ---

Link to comment

Those specific commands work fine because they’re extremely limited, can’t act on selected items, rely only on system commands, and don’t take into account your own choices/customisations. This workflow was made exactly to bypass those limitations.

If you have selected files/directories (or just a Finder window open in front) and want to act directly on them without having to write their path on Alfred, you need some of this extra complexity. The workflow also takes into account if you use zsh instead of bash, which matters if you’re used to the small differences between them. It also matters to read your shell’s startup files (which Alfred does not do on its own), which will load your specific configurations, like aliases and your PATH, which in turn allows you to run tools you have installed yourself that might reside in specific locations (like the ones installed via homebrew).

Your example works only on extremely basic examples that have, for the most part, no practical use. Most of the time you need to do something custom, something that works like your shell, the way you have it configured, does. A simple /bin/bash Run Script block gives you nothing more than what the terminal does as soon as you install the system; RunCommand gives you your environment, the way you’ve set it up, and the possibility to act directly on selected items.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...