The macOS Shortcuts app for command-line people: when a Shortcut is actually worth it vs a 5-line shell script

If you live in a terminal, the macOS Shortcuts app feels like a toy. Drag-and-drop blocks, no version control, no diff, no set -e, no way to grep through what you wrote last month. Why would anyone use it when a five-line shell script would do the same job and live in ~/bin with everything else?

Because the Shortcuts app does some things a shell script genuinely cannot, and the shell does some things Shortcuts will never be good at. After a year of using both side by side, I have a clear opinion on which to reach for. Here’s the line.

When a shell script is obviously right

  • Anything that pipes text or processes files in bulk. Renaming 200 photos with exiftool, batch-converting .heic to .jpg, grepping a log directory. Shortcuts can do these but it’s painful — the equivalent shell pipeline is shorter and faster.
  • Anything that needs git, ssh, rsync, brew, or any CLI tool. Shortcuts technically has a “Run Shell Script” action, but at that point you’re writing a shell script with extra clicks.
  • Anything you want to source-control or share with a team. A shell script is a text file. A Shortcut is a binary plist. Code review of a Shortcut means screen-sharing.
  • Anything that runs on a Linux server too. Even if you only run it on macOS today, the future you who SSHes into a VPS will thank you.

When Shortcuts is actually the right answer

Shortcuts has access to things shell scripts can’t reach — system services exposed only through Apple’s automation framework, with no CLI surface. That’s where it earns its place.

  • Anything that talks to first-party Apple apps. “Add a reminder for the highlighted text” works with one Shortcuts action. Doing it from a shell would mean reverse-engineering the Reminders private API and writing AppleScript.
  • Anything triggered by the share sheet. A Shortcut can be a share-sheet target on iOS and macOS. Shell scripts can’t.
  • Anything triggered by Siri or a hardware button. “Hey Siri, start focus mode” or assigning a Shortcut to the iPhone 15 Pro Action Button is uniquely Shortcuts territory.
  • Anything that needs a UI. Picking from a list, prompting for input, showing a toast notification, displaying a result in an alert — Shortcuts has clean built-in actions for these. In a shell script, you’d be wrangling osascript.
  • Anything that uses photo library, contacts, calendar, location, or HomeKit. All gated behind macOS’s TCC permission system. Shortcuts gets the permission grant once and then has it. Shell scripts have to convince TCC each time, badly.
  • Anything that runs on the Watch. A Shortcut can be a complication or a watchOS app entry point. A shell script can’t run on watchOS at all.

A concrete example: “Save this article”

Say you want to save the URL of an article you’re reading to a markdown file in your notes folder. Two implementations:

Shell script approach:

#!/usr/bin/env bash
# ~/bin/save-article
URL=$(pbpaste)
TITLE=$(curl -sL "$URL" | grep -oE '<title>[^<]+' | head -1 | sed 's/<title>//')
DATE=$(date +%Y-%m-%d)
echo "- [$TITLE]($URL)" >> ~/notes/inbox.md
osascript -e 'display notification "Saved" with title "Reading List"'

Works perfectly. But to use it, you have to: copy the URL, drop into Terminal, run save-article. Five seconds of context switch every time.

Shortcuts approach:

1. Receive URLs from Share Sheet  (the input)
2. Get Name of URL                (auto-extracts <title>)
3. Format Date as YYYY-MM-DD
4. Build text:  "- [{title}]({url})"
5. Append to file: ~/notes/inbox.md
6. Show Notification: "Saved"

The Shortcut wins not because the logic is better — it’s the same logic — but because it shows up in the Safari share sheet. One tap from any web page, no terminal, no copy/paste. The same 30 seconds of automation gets used 10x more often.

The hybrid pattern that works best

The cleanest pattern: Shortcut as the trigger and UI, shell script as the engine. Build a tiny Shortcut whose only action is “Run Shell Script” pointing to your real script in ~/bin. The Shortcut handles the share-sheet binding, the Siri trigger, the keyboard-shortcut binding. The shell script does the real work and lives in your dotfiles repo where you can diff it.

# Shortcut with one action:
# "Run Shell Script" (zsh)
#   Pass input as: stdin
#   Script:
/Users/me/bin/save-article "$0"

Now the script is text, version-controlled, testable from a terminal, runnable on a server. The Shortcut is just the “here’s where it shows up in macOS” glue.

The decision rule, condensed

  • Pure data transformation, file ops, network I/O. → Shell script. Always.
  • Needs to talk to first-party Apple apps or be triggered by Siri / share sheet / Action button. → Shortcut, or hybrid (Shortcut wraps shell script).
  • Needs to run on Linux too. → Shell script, no exceptions.
  • Will be run more than 5 times a day. → Whichever has lower friction, which usually means a Shortcut for the trigger surface.
  • Has any complexity beyond ~10 actions. → Shell script. Shortcuts becomes hard to read past that and offers no debugger.

Shortcuts isn’t a replacement for the shell. It’s a trigger and UI layer that the shell doesn’t have on macOS. Once you stop trying to write logic in it and start using it as the “put my scripts in places where they’re easy to invoke” system, the two stop competing and start composing nicely.

Photo: Laptop with code editor and coffee mug by dkomov on Pexels.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.