Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to set up a few keyboard shortcuts that open specific iTerm sessions, which I was able to do with BetterTouchTool and a bit of AppleScript magic. The problem is that OS X insists to open a Terminal window for any shell script you execute through the GUI (i.e. from Finder, or as a keyboard shortcut from BetterTouchTool). The terminal window doesn't appear if I run the script directly from another terminal.

A workaround I found was to wrap the script in an .app directory, which solves the problem of the superfluous terminal window, but has some other issues (for example OS X seems to treat each resulting iTerm window as a separate app, cluttering my dock). (EDIT: this behaviour was actually caused by a bug in my script, see below)

I also tried assigning the Terminal app to another virtual desktop in the Spaces settings in an attempt to move it out of sight, but then it will just first switch to that desktop before running the script.

Is there a way to disable this behaviour completely? I already found the setting in the Terminal preferences to close the window after the script has finished, but it's still annoying to have the Terminal window pop up for a second.

share|improve this question
Sorry, I don't quite understand. What do you want to do with those shell scripts? Do you want to open iTerm though a shell script? Are you exclusively talking about or mixing iTerm with "Terminal" in your question? Could you maybe post an example of what you're trying to run? – slhck Nov 22 '11 at 12:37
I've setup several iTerm sessions to launch a normal shell, open a Rails console, display the Rails log etc. I'm using iTerm exclusively, and Terminal is opened automatically by OS X for whatever silly reason. But anyway, I found a solution to make the bundle approach work properly (see edited question). – toupeira Nov 22 '11 at 14:20
I see! Well, it would be awesome if you could answer your own question (using the button below) and tell us what you did, or how you solved the issue. Maybe post some examples in your question, and then just add a brief answer. This way, if somebody stumbles upon your post, they might learn something from it! – slhck Nov 22 '11 at 14:25
Well I still don't have an answer for the actual question (i.e. how to avoid the Terminal completely, without having to use an .app wrapper), so I'd rather leave it open in case somebody can enlighten me. – toupeira Nov 22 '11 at 14:39
I'm still confused. You don't want to run them via an .app created by Automator? – slhck Nov 22 '11 at 15:03

Open Automator, choose Application, add a Run Shell Script action and put in your Shell command between quotes (if you have a file, you can just drag and drop it).

Other than playing it, now you can save it (as an app anywhere) and even set the icon.

share|improve this answer
I tried to run a command this way from a full-screen app, however it always opened it in the background. I had to background the command in the shell in a non-blocking fashion by appending a & and then call an AppleScript to bring the app (in my case mplayer) to the front: mplayer myvideo.avi &; osascript -e 'tell application "System Events" to set frontmost of the first process whose displayed name is "mplayer" to true' – Lenar Hoyt Jan 20 '15 at 14:39
Cool hack @mcb. But I don't get why. Usually we want to hide the terminal window because it will open another window, which is the main one. If you need mplayer's first terminal window, I suppose it doesn't open another one and so why would you want to hide it in the first place? – cregox Jan 20 '15 at 17:27
I’m using mplayer to play a video from within a slideshow (in Skim). There is a bug that the player stays in the background if Skim is set to fullscreen, I’m not sure though, whether this bug is only related to Skim or all fullscreen apps, so I figured I would post my solution here. – Lenar Hoyt Jan 21 '15 at 2:53

Here's a small workaround, in case you fancy application launchers like Alfred. I use it every day, and I've bought the Powerpack, which allows you to run silent shell scripts.

enter image description here

These will not open a terminal when running and can be bound to any keyword sequence. They can even include parameters, and have additional options:

enter image description here

I use this for some small snippets, and it's very flexible.

share|improve this answer
This is no longer available under Alfred 2. Instead, create a "Run Script" as shown in the picture. – Dave Newton Nov 14 '13 at 14:11

You might want to check out Platypus, which creates Mac OS X applications from shell scripts and other interpreted scripts.

share|improve this answer

If you add key LSUIElement and set it to 1 in Info.plist of your app, it will not create an icon in Dock.

Here is Info.plist of my small shell script app:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "">
<plist version="1.0">
share|improve this answer
Thanks, but this doesn't seem to have an effect. I also tried touching the bundle to make sure the newest version was used. But anyway, I don't really like the bundle approach because it seems it will always create separate app instances – toupeira Nov 22 '11 at 12:31
For me touch did not help also (I tried to switch off LSUIElement), there is some other sort of caching, but compressing and extracting application helped. Why don't you like bundle approach? Also you can use applescript and just run do shell script "say 'arsti'", this will not open terminal window. – tig Nov 22 '11 at 12:47
Okay, turns out I'm just an idiot ;-) I couldn't find a reliable way to check if an app is already running with AppleScript, so I used a normal bash script which calls pgrep, and then passes the relevant code directly to osascript (the AppleScript interpreter). The problem is that pgrep came from Homebrew, and isn't in the default $PATH. So my script always launched a new iTerm instance, even if it was already running. After adding the full path to pgrep in the script the bundle approach seems to work fine after all, so I think I'm happy for now ;-) – toupeira Nov 22 '11 at 14:18

Here's a bit of a workaround:

Compile an applescript that calls a shell script :)

osacompile -e 'do shell script "cd ~; echo aaa > temp.txt"' -o ~/name_of_script.scpt

The osacompile will compile the 'do shell script "XXX"' applescript snippet. Your shell script is the XXX.

Watch out for quoting, the shell script has to be quoted properly to get past the shell you're using to compile it still intact.

But this can be run from BetterTouchTool without any whacky-ness.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .