Come posso eseguire un'applicazione con argomenti della riga di comando in Mac OS

A partire da OS X 10.6.2, il comando open può passare argomenti all'applicazione che apre per mezzo del flag –args. Un AppleScript per usarlo assomiglia a questo:

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

Questo dovrebbe darvi tutto il comportamento che volete.

Ecco la mia soluzione migliore: Creare un Applescript con:

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

E salvatelo come applicazione.

Potete mettere qualsiasi applicazione con qualsiasi args nella prima parte. La parte dopo lo & deve uccidere qualsiasi nome abbiate dato al vostro script + .app. Vedrete l'applicazione script lampeggiare nel dock, ma poi scomparirà.

Nota: Lo script non funzionerà correttamente quando viene eseguito da Script Editor, solo quando viene eseguito dall'applicazione script che hai creato.

Aprite Automator e create una Application con una singola azione Run Shell Script:

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

Questa applicazione avvierà Firefox e uscirà istantaneamente, lasciando solo Firefox in esecuzione.

In alternativa, create un'applicazione usando AppleScript Editor con il seguente codice AppleScript:

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

Entrambi funzionano bene e non mantengono né il Terminale né un'applicazione script in esecuzione per più di un secondo o giù di lì. Usando Automator, potete anche creare un Service se lo scegliete.

Non è necessario (come alcune altre risposte hanno suggerito) usare killall (o simili) per uccidere il processo applicativo AppleScript padre (“applet”) in questo scenario. Può anche avere effetti collaterali spiacevoli se il nome/pattern dato a killall corrisponde a più del solo processo applet padre (ad esempio altre applicazioni AppleScript in esecuzione simultanea (se si usa “applet” come pattern)).

Qualcosa come kill $PPID potrebbe essere più ragionevole, ma potremmo non voler assumere che l'applet di un'applicazione AppleScript sia sempre il genitore immediato della shell avviata da do shell script. Fortunatamente, c'è un modo perfettamente ragionevole per fare ciò di cui avete bisogno.

Per TN2065 (sotto “Voglio avviare un processo server in background; come faccio a fare in modo che do shell script non aspetti fino al completamento del comando?”), il metodo corretto è quello di reindirizzare stdout e stderr e far eseguire alla shell il programma in background.

Usa Script Editor per salvare il seguente programma come applicazione AppleScript:

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

(aggiunte interruzioni di linea funzionali per mantenerlo “stretto”; cancellate i punti ¬ e \ e mettete tutto su una lunga linea se volete)

Verrà eseguito abbastanza a lungo da avviare Firefox e uscirà in modo pulito mentre Firefox continua a funzionare.

Il reindirizzamento è necessario perché non solo do shell script aspetta che il suo figlio immediato (la shell) esca, ma aspetta anche che (tutte le istanze di) le estremità scrivibili delle pipe che crea per stdout e stderr della shell siano chiuse. Lo stdout e lo stderr della shell (le pipe di do shell script) sono ereditate dai programmi che esegue senza reindirizzamento (anche quelli eseguiti in background con &); il reindirizzamento assicura che la shell sia l'ultima a tenere le estremità scrivibili delle pipe. Così, do shell script ritornerà immediatamente dopo l'uscita della shell, permettendo all'applicazione AppleScript stessa di uscire (poiché il do shell script è l'ultima espressione del programma AppleScript).

Le altre risposte che usano open dentro do shell script funzionano perché open (in realtà LaunchServices) fa l'equivalente lavoro di mettere in background il programma risultante e mandare i suoi stdout e stderr altrove.

Questa è una vecchia discussione, ma viene ancora fuori nelle ricerche su Google, quindi ho pensato di aggiungere un paio di ¢.

Probabilmente è meglio usare un “bundle identifier” piuttosto che il percorso assoluto dell'eseguibile:

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

O in un Apple Script:

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

Quello che non ho ancora capito è come aprire una nuova istanza/finestra con un profilo diverso quando la prima è già aperta. (Se eseguo l'AppleScript di cui sopra, poi un altro con “Profilo 2”, allora Chrome aprirà ancora solo un'altra finestra come “Profilo 1”). :(

AppleScript

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

Due punti qui.

1. Lo spazio è evaso da un backslash che è evaso di nuovo da backslash
2. killall applet può causare problemi, perché ci possono essere altre applet in esecuzione
3. Salvarlo come programma

Comunque funziona bene su 10.6.5

Quanto segue dovrebbe permetterti di specificare gli argomenti della riga di comando per la .app stessa:

Fai clic destro sul bundle .app, seleziona “Show Package Contents”, naviga fino a Info.plist, fai doppio clic su di esso, trova la chiave Args, modifica.

Non ho una macchina OS X a portata di mano in questo momento, quindi non posso controllare se si può fare questo anche per un alias (se si vuole mantenere l'originale .app senza argomenti, eccetera).

Avvolgete la vostra applicazione in un launcher AppleScript.

Ecco i passaggi.

1. Create un AppleScript con il seguente contenuto e salvatelo come applicazione (in questo esempio si chiama “Firefox 3 launcher.app”).

2. Raggiungete quell'applicazione nel Finder, cliccate con il tasto destro e mostrate il contenuto del pacchetto.

3. Metti la tua applicazione nella radice del contenuto del pacchetto. (In questo esempio sarebbe “Firefox 3.app”)

4. Ora puoi aprire il tuo lanciatore di applicazioni.

Note:

• Gli aggiornamenti automatici dell'applicazione wrapped dovrebbero funzionare nella maggior parte dei casi.
• Dovrebbe essere possibile fare in modo che qualsiasi trascinamento nel lanciatore sia automaticamente reindirizzato all'applicazione nascosta (con un po’ più di scripting).
• Il lanciatore esce automaticamente dopo il lancio dell'applicazione compressa.
• Un vantaggio di questo metodo è che ci sono pochi rischi di aprire direttamente l'applicazione wrapped.

Il comando open ha un argomento opzionale --args il cui valore sarà passato all'applicazione aperta come argomento. Per esempio:

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