2009-08-01 09:24:24 +0000 2009-08-01 09:24:24 +0000
60
60

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

Existe-t-il un moyen simple d'ajouter des arguments de ligne de commande à une application sur un Mac ? Par exemple, pour exécuter Opera en mode kiosque ou pour utiliser un profil différent dans Firefox, je peux taper

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

Dans Windows, je peux ajouter les arguments aux propriétés des raccourcis, mais comme les Macs n'utilisent pas de raccourcis en soi et exécutent les applications directement, ce n'est pas possible.

J'ai constaté que le lancement des applications par bash ou Applescript fonctionne partiellement :

# 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"

Je peux les rendre exécutables et leur attribuer une icône et tout fonctionne très bien, sauf que lorsque j'exécute l'un de ces pseudo-programmes, une fenêtre de terminal ou une icône Applescript reste ouverte tant que l'application est ouverte. Vraisemblablement, l'utilisation de la commande Applescript open éviterait cela, mais comme je n'exécute pas l'application telle qu'elle est packagée (seulement /Applications/Firefox), cela ne fonctionne pas.

Alors, y a-t-il une meilleure façon d'exécuter des applications avec des arguments en ligne de commande ? Sinon, y a-t-il un moyen d'empêcher une session de terminal persistante ou une icône Applescript de rester ouverte pendant que l'application est en cours d'exécution ?

Editer

Selon une page Mozilla Wiki , il est préférable d'utiliser un script pour exécuter l'application avec des arguments. L'ajout d'un & à la fin du script tue la fenêtre persistante du Terminal. Le seul inconvénient maintenant est qu'il ouvre une fenêtre de Terminal morte et déconnectée (ce qui est mieux que la fenêtre persistante, mais quand même…)

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

Réponses (9)

30
30
30
2010-03-04 20:13:16 +0000

À 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.

18
18
18
2009-08-01 11:56:26 +0000

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.

14
14
14
2011-01-22 13:04:27 +0000

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.

8
8
8
2011-03-13 03:59:54 +0000

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.

8
8
8
2014-08-22 20:50:57 +0000

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”) :(

4
4
4
2011-01-22 12:48:22 +0000

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

3
3
3
2009-08-01 10:30:41 +0000

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.).

2
2
2
2011-03-22 19:32:58 +0000

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.
1
1
1
2019-03-29 23:38:35 +0000

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