Como posso executar uma aplicação com argumentos de linha de comando em Mac OS

A partir do OS X 10.6.2, o comando aberto pode passar argumentos para a aplicação que abre por meio da bandeira –args. Um AppleScript para o utilizar parece-se com isto:

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

Isso deve dar-lhe todo o comportamento que deseja.

Aqui está a minha melhor solução: Criar um Applescript com:

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

E guarda-o como uma aplicação*.

Pode colocar qualquer aplicação com qualquer args na primeira parte. A parte depois do & precisa de matar o que quer que tenha nomeado o seu guião + .app. Verá a aplicação do script a piscar na doca, mas depois desaparecerá.

Nota: O script não funcionará correctamente quando executado a partir do Script Editor, apenas quando executado a partir da aplicação script que criou.

Abrir Automador e criar uma Aplicação com uma única acção Run Shell Script:

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

Esta aplicação lançará o Firefox e sairá instantaneamente, deixando apenas o Firefox a funcionar.

Em alternativa, criar uma aplicação usando AppleScript Editor* com o seguinte código AppleScript:

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

Ambos funcionam bem e não mantêm o Terminal ou uma aplicação de script a funcionar durante mais de um segundo ou assim. Usando o Automator, pode mesmo criar um Service se assim o escolher.

Não é necessário (como algumas outras respostas sugeriram) usar killall (ou semelhante) para matar o processo de aplicação AppleScript pai (“applet”) neste cenário. Pode até ter efeitos secundários indesejáveis se o nome/padrão dado a killall corresponder a mais do que apenas o processo da applet pai (por exemplo, outras aplicações AppleScript em execução concomitante (se usar “applet” como padrão)).

Algo como kill $PPID pode ser mais razoável, mas podemos não querer assumir que a applet de uma aplicação AppleScript é sempre o pai imediato da shell iniciada por do shell script. Felizmente, existe uma forma perfeitamente razoável de fazer o que se precisa.

Por TN2065 (sob “I want to start a background server process; how do I make do shell script not wait until the command complete?”), o método adequado é redireccionar stdout e stderr e fazer com que a shell execute o programa em segundo plano.

Use Script Editor para guardar o seguinte programa como uma aplicação AppleScript:

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

(quebras de linha funcionais adicionadas para o manter “estreito”; apagar o ¬ e \ e colocar tudo numa longa linha se quiser)

Correrá o tempo suficiente para iniciar Firefox e sairá limpo enquanto Firefox continua a correr.

O redireccionamento é necessário porque não só do shell script espera que o seu filho imediato (a shell) saia, mas também espera (todas as instâncias de) as extremidades escrevíveis dos tubos que cria para que a stdout e stderr da shell sejam fechadas. A shell stdout e stderr (do shell script‘s pipes) são herdadas pelos programas que corre sem redireccionamento (mesmo os que correm em fundo com &); o redireccionamento assegura que a shell é a última a segurar as extremidades escrevíveis dos tubos. Assim, do shell script voltará imediatamente após a saída da shell, permitindo que a própria aplicação AppleScript saia (visto que o do shell script é a última expressão no programa AppleScript).

As outras respostas que utilizam open dentro de do shell script funcionam porque open (na realidade LaunchServices) faz o trabalho equivalente de fundo do programa resultante e envia o seu stdout e stderr para outro local.

Esta é uma discussão antiga, mas ainda aparece nas pesquisas do Google, por isso pensei em adicionar um par de ¢.

É provavelmente melhor usar um “identificador de pacote” em vez de um caminho absoluto para o executável:

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

Ou num Apple Script:

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

O que ainda não descobri é como abrir uma nova instância/janela com um perfil diferente, uma vez que a primeira já esteja aberta. (Se eu executar o AppleScript acima, então outra com “Perfil 2”, então o Chrome ainda só abrirá outra janela como “Perfil 1”) :(

AppleScript*

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

Dois pontos aí.

1. o espaço é escapado por uma contrabarra que é novamente escapado por uma contrabarra
2. killall applet pode causar problemas, porque pode haver outras applets a correr
3. Guarde-a como programa

Contudo funciona bem em 10.6.5

O seguinte deve permitir-lhe especificar os argumentos da linha de comando para o próprio .app:

Clique com o botão direito do rato no pacote .app, seleccione “Mostrar conteúdo do pacote”, navegue para Info.plist, faça duplo clique, encontre a tecla Args, edite.

Não tenho uma máquina OS X à mão neste momento, por isso não posso verificar se também poderia fazer isto a um pseudónimo (se quisesse manter o original .app livre de argumentos, et cetera).

Embrulhe a sua aplicação dentro de um lançador AppleScript.

Aqui estão os passos.

1. Crie um AppleScript com o seguinte conteúdo, e guarde-o como uma aplicação (neste exemplo chama-se “Firefox 3 launcher.app”).

2. Chegou a essa aplicação no Finder, clique com o botão direito do rato, mostrar o conteúdo do pacote.

3. Coloque a sua aplicação na raiz do conteúdo do pacote. (Neste exemplo seria “Firefox 3.app”)

4. Pode agora abrir o lançador da sua aplicação.

Notas:

• As actualizações automáticas da aplicação embrulhada devem funcionar na maioria dos casos. & - Deve ser possível fazer qualquer arrastar e largar para o lançador automaticamente redireccionado para a aplicação embrulhada (com um pouco mais de scripting).
• O lançador sai automaticamente após o lançamento da aplicação embrulhada.
• Uma vantagem deste método é que há poucos riscos de abrir directamente a aplicação embrulhada.

O comando open tem um argumento opcional --args que o seu valor será transmitido para a aplicação aberta como argumentos. Por exemplo:

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