Je fais pas mal de travail en ligne de commande, et je me retrouve à définir pas mal d'alias du formulaire:
alias skim='/Applications/Skim.app/Contents/MacOS/Skim'
Existe-t-il un moyen d'ajouter de la magie de telle sorte que demander l'exécutable "foo" utilise automatiquement l'exécutable /Applications/Foo.app/Contents/MacOS/Foo? C'est sur OS X 10.6.
(Je sais que je pourrais le faire open foo.pdf
, mais Skim n'est pas le lecteur PDF par défaut, et j'aimerais une solution générale - dans certains cas, il n'est pas approprié de définir l'application en question comme gestionnaire par défaut du fichier.)
open -a Skim foo.pdf
.Réponses:
Enfin j'ai compris: ajoutez ceci à votre
.bash_profile
Maintenant, le travail suivant:
Édité par Reid:
J'ai implémenté ce qui précède comme un script Python qui crée des scripts wrapper au lieu d'alias. Vous devrez mettre
~/bin/mankoffmagic
votre chemin. Si vous souhaitez que les wrappers soient mis à jour automatiquement, exécutez-le régulièrement à partir de cron ou somesuch.la source
ls
commande, et cela fonctionnera là aussi.Vous n'avez besoin de rien d'extraordinaire, vous avez déjà la réponse. Essayer:
open /Applications/Foo.app bar.pdf
lors de l'édition
À la lumière des commentaires ci-dessous, je pense que ma réponse serait encore relativement similaire ... Je ferais une fonction qui remplace open, fait un pushd to
/Applications
, appelle/usr/bin/open $appName.app $args
, fait un popd et retourne.Je crains les scripts shell mais quelque chose comme ci-dessous qui couvre des cas spéciaux et vous permet d'utiliser à peu près la même syntaxe qu'Apple pour open. J'aime garder mon environnement aussi propre que possible.
Je suis sûr que la syntaxe vient de l'espace:
au deuxième montage
en regardant le commentaire de @ mankoff sur la question d'origine, la plupart des éléments de la fonction ci-dessus seraient probablement une perte de temps car vous pourriez simplement l'utiliser
open -a $appName
. Donc mankoff a probablement la solution la plus simple et devrait changer son commentaire en réponse;)la source
Il y a deux solutions auxquelles je peux penser:
La manière la plus simple - En utilisant le
Info.plist
fichier dans chaqueContents
répertoire .app , créez un index de la valeur pour les clés CFBundleExecutable. Ajoutez ensuite un alias court qui appelle un script (perl, python, peu importe) avec le nom d'un exécutable et les arguments que vous souhaitez transmettre.Votre index serait constitué de paires de noms d'exécutables et de chemins d'accès à ces exécutables. Vous devez écrire un script planifié récurrent pour le garder à jour.
Vous pourriez finir par appeler:
où f est un alias d'un script qui vérifie votre index pour un exécutable nommé
foo
.Dans l'ensemble, pas beaucoup de travail pour obtenir les fonctionnalités que vous souhaitez.
La manière la plus difficile - Étendez votre shell pour compléter la gestion de son
command_not_found
erreur. Essentiellement, vous implémenteriez unemethod_missing
fonctionnalité de style Ruby dans le shell que vous utilisez. Une foiscommand_not_found
lancé, votre méthode vérifierait les noms des exécutables de vos applications installées.la source
Applescript à la rescousse:
Remplacez le nom de l'application par l'application que vous souhaitez démarrer et vous avez terminé. Vous pouvez bien sûr en faire une fonction shell si besoin:
et utilisez-le de cette façon:
Je déteste applescript, mais c'est parfois utile, et je crois que la seule façon d'adresser une application simplement par son nom sur la ligne de commande. Tout le reste nécessitera un chemin complet.
la source