How can I run an application with command line arguments in Mac OS

Question

Is there any easy way to append command line arguments to an application on a Mac? For example, to run Opera in kiosk mode or to use a different profile in Firefox, I can type

$ /Applications/Opera.app/Contents/MacOS/Opera -kioskmode
$ /Applications/Firefox.app/Contents/MacOS/firefox -P profilename -no-remote

In Windows I can append the arguments to the shortcut properties, but since Macs don't use shortcut per se and run the applications directly, this isn't possible.

I have found that launching the applications through bash or Applescript partially works:

# Bash
#!/bin/sh
/Applications/Firefox.app/Contents/MacOS/firefox -P default -no-remote

# Applescript    
do shell script "exec /Applications/Opera.app/Contents/MacOS/Opera -kioskmode"

I can make these executable and assign an icon and everything works great except that when I run either of these pseudo programs, either a terminal window or an Applescript icon remains open as long as the application is open. Presumably, using the Applescript command open would avoid this, but since I'm not running the application as it is packaged (just /Applications/Firefox), it doesn't work.

So, is there a better way to run applications with command line arguments? If not, is there a way to prevent a persistent terminal session or Applescript icon from staying open while the application is open?

Edit

According to a Mozilla Wiki page, it's best to use a script to run the application with arguments. Adding a & to the end of the script kills the persistent Terminal window. The only annoyance now is that it opens a dead, logged out Terminal window (which is better than the persistent one, but still...)

#!/bin/sh
/Applications/Firefox.app/Contents/MacOS/firefox -P default -no-remote &

Answer 1

This answer is obsolete.

Refer to other answers for modern Mac OS.

Here's my best solution: Create an Applescript with:

do shell script "/Applications/Firefox.app/Contents/MacOS/firefox -P default -no-remote & killall Firefox.app"

And save it as an application.

You can put whatever application with whatever args in the first part. The part after the & needs to kill whatever you have named your script + .app. You'll see the script app flash up in the dock, but it will then disappear.

Note: The script will not work properly when run from Script Editor, only when run from the script application you have created.

Answer 2

Starting in OS X 10.6.2, the open command can pass arguments to the application it opens by way of the --args flag. An AppleScript to use it looks like this:

do shell script "open -a /Applications/Firefox.app --args -P default -no-remote"

That should give you all the behavior you want.

Answer 3

Open Automator and create an Application with a single Run Shell Script action:

 /Applications/Firefox.app/Contents/MacOS/firefox-bin -here-some-args &

This application will launch Firefox and quit instantly, leaving only Firefox running.

---

Alternatively, create an application using AppleScript Editor with the following AppleScript code:

do shell script "open -a '/Users/danielbeck/Applications/Firefox.app' --args -ProfileManager"

Both work fine and don't keep either Terminal or a script application running for more than a second or so. Using Automator, you can even create a Service if you choose so.

Answer 4

The open command has an optional --args argument that's value will be passed on to the opened application as arguments. For example:

open /Applications/TextEdit.app --args example.txt

Answer 5

This is a old discussion, but still comes up on Google searches, so I thought I'd add a couple of ¢.

It's probably better to use a "bundle identifier" rather than absolute path to the executable:

open -b com.google.Chrome --args --profile-directory="Profile 1"

Or in an Apple Script:

do shell script "open -b com.google.Chrome --args --profile-directory='Profile 1'"

What I have not figured out yet is how to open a new instance/window with a different profile once the first one is already open. (If I run the AppleScript above, then another with "Profile 2", then Chrome will still just open another window as "Profile 1"). :(

Answer 6

It is not necessary (as some other answers have suggested) to use killall (or similar) to kill the parent AppleScript application process (“applet”) in this scenario. It can even have untoward side effects if the name/pattern given to killall matches more than just the parent applet process (e.g. other, concurrently running AppleScript applications (if using “applet” as the pattern)).

Something like kill $PPID might be more reasonable, but we may not want to assume that the applet of an AppleScript application is always the immediate parent of the shell started by do shell script. Luckily, there is a perfectly reasonable way to do what you need.

Per TN2065 (under “I want to start a background server process; how do I make do shell script not wait until the command completes?”), the proper method is to redirect stdout and stderr and have the shell run the program in the background.

Use Script Editor to save the following program as an AppleScript application:

do shell script ¬
    "/Applications/Firefox.app/Contents/MacOS/firefox-bin \\
        -P default -no-remote \\
        >/dev/null 2>&1 &"

_{(functional line breaks added to keep it “narrow”; delete the ¬ and \\ and put it all on one long line if you like)}

It will run long enough to start Firefox and will exit cleanly while Firefox continues to run.

The redirection is required because not only does do shell script wait for its immediate child (the shell) to exit, but it also waits for (all instances of) the writable ends of the pipes it creates for the shell’s stdout and stderr to be closed. The shell’s stdout and stderr (do shell script’s pipes) are inherited by the programs it runs without redirection (even ones run in the background with &); the redirection ensures that the shell is the last one to hold the writable ends of the pipes. Thus, do shell script will return immediately after the shell exits, allowing the AppleScript application itself to exit (since the do shell script is the last expression in the AppleScript program).

The other answers that use open inside do shell script work because open (actually LaunchServices) does the equivalent work of backgrounding the resulting program and sending its stdout and stderr elsewhere.

Answer 7

AppleScript

do shell script "/Applications/Google\\ Chrome.app/Contents/MacOS/Google\\ Chrome --incognito & killall applet"

Two points there.

1. The space is escaped by a backslash which is escaped by backslash again
2. killall applet can cause troubles, because there may other applets running
3. Save it as program

However it works well on 10.6.5

Answer 8

The following should let you specify command-line arguments for the .app itself:

Right click .app bundle, select "Show Package Contents", navigate to Info.plist, double click it, find Args key, edit.

I don't have an OS X machine handy right at the moment, so I can't check whether you could also do this to an alias (if you wanted to keep the original .app argument-free, et cetera).

Answer 9

Wrap your application inside an AppleScript launcher.

Here are the steps.

1. Create an AppleScript with the following content, and save it as an application (in this example it is named "Firefox 3 launcher.app").

   set pathToApp to (POSIX path of (path to me)) & "Firefox 3.app"
   do shell script "open -a \"" & pathToApp & "\" --args -P default -no-remote"
   

2. Got to that app in the Finder, right click it, show package contents.

3. Put your application in the root of the package contents. (In this example it would be "Firefox 3.app")

   Result: /Applications/Firefox 3 launcher.app/Firefox 3.app

4. You may now open your application launcher.

Notes:

• Automatic updates of the wrapped application should work in most cases.
• It should be possible to make any drag and drop to the launcher automatically redirected to the wrapped application (with a bit more scripting).
• The launcher automatically exits after the wrapped application is launched.
• An advantage of this method is that there is few risks of opening the wrapped application directly.

Answer 10

Why don't you use:

#!/bin/sh
open /Applications/Firefox.app

Simple but it works.