Jest to wykonalne, ale prawdopodobnie nie jest tak proste, jak mogłoby się wydawać. Musisz bardzo dobrze zapoznać się z identyfikatorami typu jednolitego. Zajrzyj na stronę Uniform Type Identifier w Wikipedii .
System OS X przechowuje informacje o preferowanych powiązaniach plików w pliku preferencji o nazwie com.apple.LaunchServices.plist
. Zanim zaczniesz szukać i modyfikować ten plik, sugeruję zapoznanie się z hierarchią domen OS X w zakresie ustawień domyślnych (inaczej „ustawienia”). Przyzwoity artykuł na ten temat można znaleźć tutaj . (Uwaga: wydaje się, że coś sprzedają na tej stronie. Nie wiem, co to jest i nie mam z nimi żadnego związku, wyjaśnienie jest po prostu dobre.)
Teraz, gdy wiesz wszystko o ustawieniach domyślnych i interfejsach użytkownika (er, nie o charakterze medycznym), teraz możemy mówić o ustawianiu skojarzeń plików ze skryptu / wiersza poleceń.
Najpierw musisz znać właściwy sposób identyfikowania plików, dla których chcesz utworzyć powiązanie.
Pamiętasz, jak powiedziałem, że ZUM są ważne? Istnieje wiele sposobów identyfikacji pliku. Zależy to od tego, czy typ został formalnie zadeklarowany w systemie, czy nie. Na przykład przyzwoite edytory tekstu, takie jak TextMate lub TextWrangler, dodadzą całkiem sporo deklaracji typów do hierarchii typów, gdy używasz ich w systemie. Jeśli jednak nie masz tych aplikacji, możesz nie zadeklarować tych typów.
OK, wystarczy gadać. Przykłady:
Uzyskaj identyfikator UTI dla pliku:
$ mdls myFile.xml
...
kMDItemContentType = "public.xml"
kMDItemContentTypeTree = (
"public.xml",
"public.text",
"public.data",
"public.item",
"public.content"
)
...
Ok fajnie. Wyraźny typ treści, którego możemy użyć. Zapisz to gdzieś.
$ mdls myFile.myExtn
...
kMDItemContentType = "dyn.ah62d4rv4ge8048pftb4g6"
kMDItemContentTypeTree = (
"public.data",
"public.item"
)
...
Ups OS X nie wie o plikach „.myExtn”. Stworzyło to dynamiczny interfejs użytkownika, którego nie możemy wykorzystać do niczego. A typy nadrzędne są zbyt ogólne, aby były przydatne.
Teraz, gdy wiemy, jakie są nasze pliki, spójrzmy na plik LaunchServices.plist i zobaczmy, co możemy zrobić:
$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";
},
...
);
...
}
Tak więc, gdy masz „dobry” typ zawartości do użycia, pierwsza konstrukcja jest lepsza. W przeciwnym razie inny konstrukt. Zauważ, że w tym pliku znajdują się inne konstrukcje, ale nie mają one związku z tym, o co prosiłeś. Tylko wiedz, że są one dostępne, gdy przeglądasz dane wyjściowe.
Jak widać, musisz znaleźć interfejs użytkownika dla aplikacji, której chcesz użyć. Interfejsy użytkownika dla Safar i TextMate znajdują się w moim przykładzie powyżej, ale ogólnie znajdują interfejs użytkownika dla aplikacji:
$ cd /Applications/MyApp.app/Contents
$ less Info.plist
...
<key>CFBundleIdentifier</key>
<string>com.apple.Safari</string>
...
UWAGA: Nie mam żadnego pojęcia, co stanowi różnicę pomiędzy LSHandlerRoleAll i LSHandlerRoleViewer. Nigdzie nie mogę znaleźć dokumentacji na ten temat. Co mam zrobić, widzę to, że 99% czasu LSHandlerRoleAll jest tylko jeden zestaw (czyli nie ma LSHandlerRoleViewer w ogóle) i że jest ona ustawiona na ZUM do wniosku, że pragnienie skojarzyć typ z.
Zaprowadząc cię tak daleko, opuszczę HOW, aby ustawić wartości, które chcesz, jako ćwiczenie dla czytelnika. Bałagan z tymi rzeczami może być nieco niebezpieczny. Całkowicie możliwe jest zepsucie pliku i brak działania ŻADNEGO powiązania plików. Następnie musisz wyrzucić plik i zacząć od nowa.
Kilka wskazówek:
- Czytaj dalej
defaults write
i jego składnia
- Spójrz na
PlistBuddy
. man PlistBuddy
i/usr/libexec/PlistBuddy -h
- Pomiń wszystkie te bzdury i użyj RCDefaultApp