Questo è fattibile, ma probabilmente non è così semplice come si potrebbe pensare. Avrai bisogno di familiarizzare con gli identificatori di tipo uniforme. Guarda la Identificatore di tipo uniforme di Wikipedia
.
OS X memorizza le informazioni sulle associazioni di file preferite in un file delle preferenze con il nome com.apple.LaunchServices.plist
. Prima di andare cerca di trovare e modificare quel file, ti suggerisco di familiarizzare con la gerarchia dei domini di OS X per i default (a.k.a. "settings"). Un articolo decente su questo può essere trovato qui . (Disclaimer: sembra che stiano vendendo qualcosa su quel sito, non so cosa sia e non abbiano alcuna associazione con loro, la spiegazione è giusta).
Ora che sai tutto su default e UTI (ehm, non sul tipo medico), ora possiamo parlare di impostare le associazioni di file da uno script / riga di comando.
In primo luogo, è necessario conoscere il modo corretto per identificare i file per i quali si desidera creare un'associazione.
Ricordi come ho detto che le UTI erano importanti? Esistono diversi modi per identificare un file. Dipende se il tipo è stato dichiarato formalmente sul tuo sistema o meno. Ad esempio, editor di testo decenti come TextMate o TextWrangler aggiungeranno alcune dichiarazioni di tipo alla gerarchia dei tipi quando li si utilizza sul proprio sistema. Se, tuttavia, non hai queste applicazioni, potresti non aver dichiarato quei tipi.
OK, basta parlare. Esempi:
Ottieni l'UTI per un file:
$ mdls myFile.xml
...
kMDItemContentType = "public.xml"
kMDItemContentTypeTree = (
"public.xml",
"public.text",
"public.data",
"public.item",
"public.content"
)
...
Ok, fico. Un tipo di contenuto esplicito che possiamo usare. Scrivilo da qualche parte.
$ mdls myFile.myExtn
...
kMDItemContentType = "dyn.ah62d4rv4ge8048pftb4g6"
kMDItemContentTypeTree = (
"public.data",
"public.item"
)
...
Spiacenti. OS X non conosce i file ".myExtn". Quindi, ha creato un UTI dinamico che non possiamo usare per nulla. E i tipi principali sono troppo generici per essere utili.
Ora che sappiamo quali sono i nostri file, vediamo il file LaunchServices.plist e vediamo cosa possiamo fare:
$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";
},
...
);
...
}
Quindi, quando si utilizza un tipo di contenuto "buono", il primo costrutto è migliore. Altrimenti l'altro costrutto. Nota, ci sono altri costrutti in quel file, ma non sono rilevanti per quello che hai chiesto. Basta sapere che sono lì quando si guarda attraverso l'output.
Come puoi vedere, dovrai trovare l'UTI per l'applicazione che desideri utilizzare. Le UTI per Safar e TextMate sono nel mio esempio sopra, ma per trovare genericamente l'UTI per un'applicazione:
$ cd /Applications/MyApp.app/Contents
$ less Info.plist
...
<key>CFBundleIdentifier</key>
<string>com.apple.Safari</string>
...
NOTA: ho un'idea no che cosa costituisce la differenza tra LSHandlerRoleAll e LSHandlerRoleViewer. Non riesco a trovare documentazione su questo ovunque. Quello che io do vedere è che il 99% delle volte LSHandlerRoleAll è l'unico set (cioè non c'è affatto LSHandlerRoleViewer) e che è impostato sull'UTI per l'applicazione che si desidera associare digita con.
Dopo averti portato così lontano, lascerò COME impostare i valori che desideri come esercizio per il lettore. Pasticciare con queste cose può essere un po 'pericoloso. È completamente possibile rovinare un file e non avere QUALUNQUE delle tue associazioni di file funzionino. Quindi devi buttare via il file e ricominciare da capo.
Alcuni suggerimenti:
- Leggi su
defaults write
e la sua sintassi
- Dai un'occhiata a
PlistBuddy
. man PlistBuddy
e /usr/libexec/PlistBuddy -h
- Salta tutte queste assurdità del tutto e usa RCDefaultApp