Comment puis-je exécuter une application avec des arguments de ligne de commande sous Mac OS

À partir d'OS X 10.6.2, la commande open peut passer des arguments à l'application qu'elle ouvre au moyen du drapeau –args. Un AppleScript pour l'utiliser ressemble à ceci :

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

Cela devrait vous donner le comportement que vous voulez.

Voici ma meilleure solution : Créer un Applescript avec :

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

Et enregistrez-le en tant qu'application.

Vous pouvez mettre n'importe quelle application avec n'importe quels args dans la première partie. La partie qui suit le & doit tuer ce que vous avez nommé votre script + .app. Vous verrez l'application du script s'afficher dans le dock, mais elle disparaîtra ensuite.

Note : Le script ne fonctionnera pas correctement s'il est exécuté à partir de l'éditeur de script, mais seulement s'il est exécuté à partir de l'application de script que vous avez créée.

Ouvrez Automator et créez une Application avec une seule action Exécuter un script shell :

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

Cette application lancera Firefox et s'arrêtera instantanément, ne laissant que Firefox en marche.

Alternativement, créer une application en utilisant AppleScript Editor avec le code AppleScript suivant :

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

Les deux fonctionnent bien et ne maintiennent ni Terminal ni une application de script en cours d'exécution pendant plus d'une seconde environ. En utilisant Automator, vous pouvez même créer un Service si vous le souhaitez.

Il n'est pas nécessaire (comme l'ont suggéré d'autres réponses) d'utiliser killall (ou similaire) pour tuer le processus d'application AppleScript parent (“applet”) dans ce scénario. Cela peut même avoir des effets secondaires fâcheux si le nom/motif donné à killall correspond à plus que le processus d'applet parent (par exemple, d'autres applications AppleScript fonctionnant simultanément (si l’“applet” est utilisé comme motif)).

Quelque chose comme kill $PPID pourrait être plus raisonnable, mais nous ne voulons peut-être pas supposer que l'applet d'une application AppleScript est toujours le parent immédiat du shell lancé par do shell script. Heureusement, il existe un moyen parfaitement raisonnable de faire ce dont vous avez besoin.

Selon TN2065 (sous “Je veux lancer un processus de serveur en arrière-plan ; comment faire en sorte que le script shell n'attende pas la fin de la commande”), la méthode appropriée consiste à rediriger stdout et stderr et à faire exécuter le programme en arrière-plan par le shell.

Utilisez Script Editor pour enregistrer le programme suivant comme une application AppleScript :

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

(sauts de ligne fonctionnels ajoutés pour garder le programme “étroit” ; supprimez les ¬ et \ et mettez le tout sur une longue ligne si vous le souhaitez)

Il s'exécutera suffisamment longtemps pour démarrer Firefox et se terminera proprement tandis que Firefox continuera à s'exécuter.

La redirection est nécessaire parce que non seulement do shell script attend que son fils immédiat (le shell) se termine, mais il attend aussi (toutes les instances de) les extrémités inscriptibles des tuyaux qu'il crée pour que les stdout et stderr du shell soient fermés. Les tubes stdout et stderr du shell (do shell script) sont hérités par les programmes qu'il exécute sans redirection (même ceux qui s'exécutent en arrière-plan avec &) ; la redirection garantit que le shell est le dernier à contenir les extrémités inscriptibles des tubes. Ainsi, do shell script reviendra immédiatement après la sortie du shell, permettant à l'application AppleScript elle-même de se terminer (puisque le do shell script est la dernière expression du programme AppleScript).

Les autres réponses qui utilisent open à l'intérieur de do shell script fonctionnent parce que open (en fait LaunchServices) fait un travail équivalent à celui de l'arrière-plan du programme résultant et envoie ses stdout et stderr ailleurs.

C'est une vieille discussion, mais qui revient toujours sur les recherches Google, alors j'ai pensé ajouter quelques ¢.

Il est probablement préférable d'utiliser un “bundle identifier” plutôt qu'un chemin absolu vers l'exécutable :

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

Ou dans un Apple Script :

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

Ce que je n'ai pas encore compris, c'est comment ouvrir une nouvelle instance/fenêtre avec un profil différent une fois que la première est déjà ouverte. (Si je lance l'AppleScript ci-dessus, puis un autre avec “Profil 2”, alors Chrome n'ouvrira qu'une autre fenêtre en tant que “Profil 1”) :(

AppleScript

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

Deux points ici.

1. l'espace est échappé par une barre oblique inversée qui est échappée par une nouvelle barre oblique inversée
2. killall applet peut causer des problèmes, parce qu'il peut y avoir d'autres applets qui fonctionnent
3. Enregistrez-le sous le programme

Cependant il fonctionne bien sur 10.6.5

Ce qui suit devrait vous permettre de spécifier les arguments de la ligne de commande pour le .app lui-même :

Cliquez avec le bouton droit de la souris sur le paquet .app, sélectionnez “Show Package Contents”, naviguez jusqu'à Info.plist, double-cliquez dessus, trouvez la touche Args, éditez.

Je n'ai pas de machine OS X sous la main pour le moment, donc je ne peux pas vérifier si vous pouvez aussi faire cela avec un alias (si vous voulez garder le .app original sans argument, etc.).

Enveloppez votre application dans un lanceur AppleScript.

Voici les étapes.

1. créez un AppleScript avec le contenu suivant, et enregistrez-le en tant qu'application (dans cet exemple, il est nommé “Firefox 3 launcher.app”).

2. Accédez à cette application dans le Finder, faites un clic droit dessus et affichez le contenu du paquet.

3. Mettez votre application à la racine du contenu du paquet. (Dans cet exemple, il s'agit de “Firefox 3.app”)

4. Vous pouvez maintenant ouvrir votre lanceur d'application.

Notes :

• Les mises à jour automatiques de l'application enveloppée devraient fonctionner dans la plupart des cas.
• Il devrait être possible de faire un glisser-déposer vers le lanceur automatiquement redirigé vers l'application intégrée (avec un peu plus de script).
• Le lanceur se ferme automatiquement après le lancement de l'application intégrée.
• Un avantage de cette méthode est qu'il y a peu de risques d'ouvrir directement l'application wrappée.

La commande open a un argument facultatif --args dont la valeur sera transmise à l'application ouverte en tant qu'argument. Par exemple :

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