¿Cómo puedo ejecutar una aplicación con argumentos de línea de comandos en Mac OS?

A partir de OS X 10.6.2, el comando open puede pasar argumentos a la aplicación que abre mediante el indicador –args. Un AppleScript para utilizarlo tiene el siguiente aspecto:

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

Eso debería darle todo el comportamiento que desea.

Esta es mi mejor solución: Crear un Applescript con:

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

Y guardarlo como aplicación.

Puedes poner cualquier aplicación con cualquier argumento en la primera parte. La parte después del & necesita matar lo que sea que hayas nombrado tu script + .app. Verás que la aplicación del script aparece en el dock, pero luego desaparecerá.

Nota: El script no funcionará correctamente cuando se ejecute desde el Editor de Script, sólo cuando se ejecute desde la aplicación de script que has creado.

Abra Automator y cree una Aplicación con una única acción Run Shell Script:

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

Esta aplicación lanzará Firefox y se cerrará instantáneamente, dejando sólo a Firefox en funcionamiento.

• *

Alternativamente, cree una aplicación usando AppleScript Editor con el siguiente código AppleScript:

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

Ambas funcionan bien y no mantienen ni el Terminal ni la aplicación de script en ejecución durante más de un segundo o así. Usando Automator, puedes incluso crear un Servicio si así lo decides.

No es necesario (como han sugerido otras respuestas) utilizar killall (o similar) para matar el proceso de la aplicación AppleScript padre (“applet”) en este escenario. Incluso puede tener efectos secundarios adversos si el nombre/patrón dado a killall coincide con algo más que el proceso padre del applet (por ejemplo, otras aplicaciones AppleScript que se ejecutan simultáneamente (si se utiliza “applet” como patrón)).

Algo como kill $PPID podría ser más razonable, pero puede que no queramos asumir que el applet de una aplicación AppleScript es siempre el padre inmediato del shell iniciado por do shell script. Por suerte, hay una forma perfectamente razonable de hacer lo que necesita.

Según TN2065 (en “Quiero iniciar un proceso de servidor en segundo plano; ¿cómo hago que do shell script no espere hasta que el comando se complete?”), el método adecuado es redirigir stdout y stderr y hacer que el shell ejecute el programa en segundo plano.

Utilice el Editor de Script para guardar el siguiente programa como una aplicación AppleScript:

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

(saltos de línea funcionales añadidos para mantenerlo “estrecho”; elimine el ¬ y el \ y póngalo todo en una línea larga si lo desea)

Se ejecutará el tiempo suficiente para iniciar Firefox y saldrá limpiamente mientras Firefox sigue ejecutándose.

La redirección es necesaria porque do shell script no sólo espera a que su hijo inmediato (el shell) salga, sino que también espera a que (todas las instancias de) los extremos escribibles de las tuberías que crea para la salida y la salida estándar del shell se cierren. La salida y la salida estándar del shell (las tuberías de do shell script) son heredadas por los programas que ejecuta sin redirección (incluso los que se ejecutan en segundo plano con &); la redirección asegura que el shell es el último en mantener los extremos escribibles de las tuberías. Así, do shell script volverá inmediatamente después de que el shell salga, permitiendo que la propia aplicación AppleScript salga (ya que el do shell script es la última expresión del programa AppleScript).

Las otras respuestas que utilizan open dentro de do shell script funcionan porque open (en realidad LaunchServices) hace el trabajo equivalente de poner en segundo plano el programa resultante y enviar su stdout y stderr a otra parte.

Esta es una discusión antigua, pero sigue apareciendo en las búsquedas de Google, así que pensé en añadir un par de ¢.

Probablemente es mejor utilizar un “identificador de paquete” en lugar de la ruta absoluta al ejecutable:

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

O en un Script de Apple:

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

Lo que aún no he averiguado es cómo abrir una nueva instancia/ventana con un perfil diferente una vez que la primera ya está abierta. (Si ejecuto el AppleScript de arriba, y luego otro con el “Perfil 2”, entonces Chrome seguirá abriendo otra ventana como “Perfil 1”). :(

AppleScript

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

Dos puntos ahí.

1. El espacio se escapa por una barra invertida que se escapa por barra invertida de nuevo
2. killall applet puede causar problemas, porque puede haber otros applets ejecutándose
3. Guárdelo como programa

Sin embargo, funciona bien en 10.6.5

Lo siguiente debería permitirte especificar los argumentos de la línea de comandos para la propia .app:

Haz clic con el botón derecho del ratón en el paquete .app, selecciona “Show Package Contents”, navega hasta Info.plist, haz doble clic en él, busca la clave Args, edita.

No tengo una máquina OS X a mano en este momento, así que no puedo comprobar si también se podría hacer esto con un alias (si se quisiera mantener el .app original sin argumentos, etcétera).

Envuelva su aplicación dentro de un lanzador AppleScript.

Estos son los pasos.

1. Cree un AppleScript con el siguiente contenido, y guárdelo como una aplicación (en este ejemplo se llama “Firefox 3 launcher.app”).

2. Ve a esa aplicación en el Finder, haz clic con el botón derecho, muestra el contenido del paquete.

3. Pon tu aplicación en la raíz del contenido del paquete. (En este ejemplo sería “Firefox 3.app”)

4. Ahora puede abrir su lanzador de aplicaciones.

Notas:

• Las actualizaciones automáticas de la aplicación envuelta deberían funcionar en la mayoría de los casos.
• Debería ser posible hacer que cualquier arrastrar y soltar al lanzador sea redirigido automáticamente a la aplicación envuelta (con un poco más de scripting).
• El lanzador sale automáticamente después de lanzar la aplicación envuelta.
• Una ventaja de este método es que hay pocos riesgos de abrir la aplicación envuelta directamente.

El comando open tiene un argumento opcional --args cuyo valor se pasará a la aplicación abierta como argumento. Por ejemplo:

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