Jak uruchomić aplikację z argumentami wiersza poleceń w systemie Mac OS

Począwszy od OS X 10.6.2, polecenie open może przekazywać argumenty aplikacji, którą otwiera, za pomocą flagi –args. AppleScript, który tego używa, wygląda tak:

do shell script "open -a /Applications/Firefox.app --args -P default -no-remote"

To powinno dać ci wszystkie zachowania, jakich oczekujesz.

Oto moje najlepsze rozwiązanie: Utwórz Applescript z:

do shell script "/Applications/Firefox.app/Contents/MacOS/firefox -P default -no-remote & killall Firefox.app"

I zapisz go jako aplikację.

W pierwszej części możesz umieścić dowolną aplikację z dowolnymi argumentami. Część po & musi zabić to, co nazwałeś swoim skryptem + .app. Zobaczysz, że aplikacja skryptu miga w doku, ale potem zniknie.

Uwaga: Skrypt nie będzie działał poprawnie, gdy zostanie uruchomiony z Edytora skryptów, tylko wtedy, gdy zostanie uruchomiony z aplikacji skryptowej, którą utworzyłeś.

Otwórz Automator i utwórz Aplikację z pojedynczą akcją Run Shell Script:

/Applications/Firefox.app/Contents/MacOS/firefox-bin -here-some-args &

Ta aplikacja uruchomi Firefoksa i natychmiast zakończy pracę, pozostawiając tylko uruchomionego Firefoksa.

Alternatywnie, utwórz aplikację używając AppleScript Editor z następującym kodem AppleScript:

do shell script "open -a '/Users/danielbeck/Applications/Firefox.app' --args -ProfileManager"

Oba działają dobrze i nie utrzymują ani Terminala, ani aplikacji skryptowej uruchomionej dłużej niż sekundę lub więcej. Używając Automatora, możesz nawet stworzyć Service, jeśli tak zdecydujesz.

Nie jest konieczne (jak sugerowały niektóre inne odpowiedzi), aby użyć killall (lub podobnego) do zabicia macierzystego procesu aplikacji AppleScript (“applet”) w tym scenariuszu. Może to nawet mieć niepożądane efekty uboczne, jeśli nazwa / wzorzec podany do killall pasuje do więcej niż tylko macierzystego procesu appletu (np. Innych, równolegle działających aplikacji AppleScript (jeśli używasz “applet” jako wzorca)).

Coś jak kill $PPID może być bardziej rozsądne, ale możemy nie chcieć zakładać, że aplet aplikacji AppleScript jest zawsze bezpośrednim rodzicem powłoki uruchamianej przez do shell script. Na szczęście istnieje całkowicie rozsądny sposób, aby zrobić to, czego potrzebujesz.

Zgodnie z TN2065 (pod “Chcę uruchomić proces serwera w tle; jak sprawić, by skrypt do powłoki nie czekał, aż polecenie się zakończy?”), właściwą metodą jest przekierowanie stdout i stderr i posiadanie powłoki uruchamiającej program w tle.

Użyj Edytora skryptów, aby zapisać poniższy program jako aplikację AppleScript:

do shell script ¬
    "/Applications/Firefox.app/Contents/MacOS/firefox-bin \
        -P default -no-remote \
        >/dev/null 2>&1 &"

(funkcjonalne podziały linii dodane, aby utrzymać go “wąskim”; usuń ¬ i \ i umieść wszystko w jednej długiej linii, jeśli chcesz)

Będzie działać wystarczająco długo, aby uruchomić Firefox i zakończy się czysto, podczas gdy Firefox nadal działa.

Przekierowanie jest wymagane, ponieważ nie tylko do shell script czeka na zakończenie pracy swojego bezpośredniego dziecka (powłoki), ale także czeka na zamknięcie (wszystkich instancji) zapisywalnych końców rur, które tworzy dla stdout i stderr powłoki. Stdout i stderr powłoki (rury do shell script) są dziedziczone przez programy uruchamiane przez nią bez przekierowania (nawet te uruchamiane w tle z &); przekierowanie zapewnia, że powłoka jest ostatnią osobą, która trzyma zapisywalne końce rur. Tak więc, do shell script powróci natychmiast po zakończeniu pracy przez powłokę, pozwalając na zakończenie pracy samej aplikacji AppleScript (ponieważ do shell script jest ostatnim wyrażeniem w programie AppleScript).

Pozostałe odpowiedzi, które używają open wewnątrz do shell script działają, ponieważ open (właściwie LaunchServices) wykonuje równoważną pracę tła programu wynikowego i wysyła jego stdout i stderr gdzie indziej.

Jest to stara dyskusja, ale wciąż pojawia się w wyszukiwaniach Google, więc pomyślałem, że dodam kilka ¢.

Prawdopodobnie lepiej jest użyć “identyfikatora pakietu”, a nie bezwzględnej ścieżki do pliku wykonywalnego:

open -b com.google.Chrome --args --profile-directory="Profile 1"

Lub w Apple Script:

do shell script "open -b com.google.Chrome --args --profile-directory='Profile 1'"

To, czego jeszcze nie rozgryzłem, to jak otworzyć nową instancję / okno z innym profilem, gdy pierwsza jest już otwarta. (Jeśli uruchomię powyższy AppleScript, a następnie kolejny z “Profilem 2”, to Chrome nadal będzie otwierał kolejne okno jako “Profil 1”) :(

AppleScript

do shell script "/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --incognito & killall applet"

Dwa punkty.

1. Spacja jest usuwana przez backslash, który jest usuwany przez backslash ponownie
2. killall applet może powodować problemy, ponieważ mogą być uruchomione inne aplety
3. Zapisz to jako program

Jednak działa to dobrze na 10.6.5

Następujące czynności powinny pozwolić ci określić argumenty wiersza poleceń dla samej .app:

Kliknij prawym przyciskiem myszy .app bundle, wybierz “Show Package Contents”, przejdź do Info.plist, kliknij go dwukrotnie, znajdź klucz Args, edytuj.

Nie mam w tej chwili pod ręką maszyny z systemem OS X, więc nie mogę sprawdzić, czy można to zrobić również z aliasem (jeśli chcesz zachować oryginalny .app wolny od argumentów, i tak dalej).

Zawiń swoją aplikację wewnątrz launchera AppleScript.

Oto kroki.

1. Utwórz AppleScript o następującej treści i zapisz go jako aplikację (w tym przykładzie nosi on nazwę “Firefox 3 launcher.app”).

2. Przejdź do tej aplikacji w Finderze, kliknij ją prawym przyciskiem myszy, pokaż zawartość pakietu.

3. Umieść swoją aplikację w głównej części zawartości pakietu. (W tym przykładzie będzie to “Firefox 3.app”)

4. Możesz teraz otworzyć launcher aplikacji.

Uwagi:

• Automatyczne aktualizacje owiniętej aplikacji powinny działać w większości przypadków.
• Powinno być możliwe, aby każdy drag and drop do launchera automatycznie przekierowywał do owiniętej aplikacji (z odrobiną więcej skryptów).
• Program uruchamiający automatycznie kończy pracę po uruchomieniu owiniętej aplikacji.
• Zaletą tej metody jest to, że istnieje niewielkie ryzyko bezpośredniego otwarcia owiniętej aplikacji.

Polecenie open posiada opcjonalny argument --args, którego wartość zostanie przekazana do otwartej aplikacji jako argument. Na przykład:

open /Applications/TextEdit.app --args example.txt