C'est faisable, mais ce n'est probablement pas aussi simple que vous le pensez. Vous devrez vous familiariser avec les identificateurs de type uniforme. Consultez le site Wikipedia Identifiant de type uniforme page.
OS X stocke les informations sur les associations de fichiers préférées dans un fichier de préférences portant le nom de com.apple.LaunchServices.plist . Avant d'essayer de trouver et de modifier ce fichier, je vous suggère de vous familiariser avec la hiérarchie des domaines d'OS X pour les valeurs par défaut (alias "paramètres"). Un article décent sur ce sujet peut être trouvé aquí . (Avertissement : il semble qu'ils vendent quelque chose sur ce site. Je ne sais pas ce que c'est et je n'ai aucune association avec eux, l'explication est juste bonne).
Maintenant que vous savez tout sur les valeurs par défaut et les UTI (euh, pas le genre médical), nous pouvons maintenant parler de la définition des associations de fichiers à partir d'un script/ligne de commande.
Tout d'abord, vous devez connaître la bonne façon d'identifier les dossiers pour lesquels vous voulez faire une association.
Tu te souviens que j'ai dit que les infections urinaires étaient importantes ? Il existe plusieurs façons d'identifier un fichier. Cela dépend si le type a été formellement déclaré sur votre système ou non. Par exemple, les éditeurs de texte décents comme TextMate ou TextWrangler ajouteront un certain nombre de déclarations de types à la hiérarchie des types lorsque vous les utiliserez sur votre système. Cependant, si vous ne disposez pas de ces applications, il se peut que ces types ne soient pas déclarés.
OK, assez parlé. Des exemples :
Obtenir l'UTI d'un fichier :
$ mdls myFile.xml
...
kMDItemContentType = "public.xml"
kMDItemContentTypeTree = (
"public.xml",
"public.text",
"public.data",
"public.item",
"public.content"
)
...
Ok, cool. Un type de contenu explicite que nous pouvons utiliser. Notez-le quelque part.
$ mdls myFile.myExtn
...
kMDItemContentType = "dyn.ah62d4rv4ge8048pftb4g6"
kMDItemContentTypeTree = (
"public.data",
"public.item"
)
...
Oups. OS X ne connaît pas les fichiers ".myExtn". Il a donc créé une UTI dynamique que nous ne pouvons utiliser pour rien. Et les types parents sont trop génériques pour être utiles.
Maintenant que nous savons quels sont nos fichiers, examinons le fichier LaunchServices.plist et voyons ce que nous pouvons faire :
$defaults read com.apple.LaunchServices
{
...
LSHandlers = (
{
LSHandlerContentType = "public.html";
LSHandlerRoleAll = "com.apple.safari";
LSHandlerRoleViewer = "com.google.chrome";
},
...
{
LSHandlerContentTag = myExtn;
LSHandlerContentTagClass = "public.filename-extension";
LSHandlerRoleAll = "com.macromates.textmate";
},
...
);
...
}
Ainsi, lorsque vous avez un "bon" type de contenu à utiliser, la première construction est préférable. Sinon, l'autre construction. Notez qu'il y a d'autres constructions dans ce fichier, mais elles ne sont pas pertinentes pour votre question. Sachez simplement qu'ils sont là lorsque vous regardez la sortie.
Comme vous pouvez le constater, vous devrez trouver l'UTI correspondant à l'application que vous souhaitez utiliser. Les UTIs pour Safar et TextMate sont dans mon exemple ci-dessus, mais pour trouver de manière générique l'UTI d'une application :
$ cd /Applications/MyApp.app/Contents
$ less Info.plist
...
<key>CFBundleIdentifier</key>
<string>com.apple.Safari</string>
...
NOTE : J'ai pas de idée de ce qui constitue la différence entre LSHandlerRoleAll et LSHandlerRoleViewer. Je ne trouve aucune documentation à ce sujet nulle part. Ce que je do est que, dans 99 % des cas, LSHandlerRoleAll est le seul défini (c'est-à-dire qu'il n'y a pas de LSHandlerRoleViewer du tout) et qu'il est défini sur l'UTI de l'application à laquelle vous souhaitez associer le type.
Après vous avoir amené jusqu'ici, je vais laisser au lecteur le soin de se demander COMMENT définir les valeurs que vous souhaitez. Jouer avec ces choses peut être quelque peu dangereux. Il est tout à fait possible de bousiller un fichier et qu'AUCUNE de vos associations de fichiers ne fonctionne. Vous devrez alors jeter le fichier et recommencer.
Quelques conseils :
- Lire la suite
defaults write et sa syntaxe
- Jetez un coup d'œil à
PlistBuddy . man PlistBuddy y /usr/libexec/PlistBuddy -h
- Laissez tomber toutes ces bêtises et utilisez RCDefaultApp
