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

Czy jest jakiś prosty sposób na dołączenie argumentów wiersza poleceń do aplikacji na komputerze Mac? Na przykład, aby uruchomić Operę w trybie kiosku lub użyć innego profilu w przeglądarce Firefox, mogę pisać

$ /Applications/Opera.app/Contents/MacOS/Opera -kioskmode
$ /Applications/Firefox.app/Contents/MacOS/firefox -P profilename -no-remote

W systemie Windows mogę dołączyć argumenty do właściwości skrótu, ale ponieważ komputery Mac nie używają skrótu per se i bezpośrednio uruchamiają aplikacje, nie jest to możliwe.

Odkryłem, że uruchamianie aplikacji przez bash lub Applescript częściowo działa:

# Bash
#!/bin/sh
/Applications/Firefox.app/Contents/MacOS/firefox -P default -no-remote

# Applescript    
do shell script "exec /Applications/Opera.app/Contents/MacOS/Opera -kioskmode"

Mogę sprawić, by były one wykonywalne i przypisały ikonę, a wszystko działa świetnie, z wyjątkiem tego, że kiedy uruchamiam jeden z tych pseudo programów, okno terminala lub ikona Applescript pozostaje otwarta, dopóki aplikacja jest otwarta. Przypuszczalnie użycie komendy Applescript openpozwoliłoby uniknąć tego, ale ponieważ nie uruchamiam aplikacji, ponieważ jest ona spakowana (tylko /Applications/Firefox), nie działa.

Czy istnieje lepszy sposób uruchamiania aplikacji z argumentami wiersza poleceń? Jeśli nie, to czy jest jakiś sposób, aby stała sesja terminalu lub ikona Applescript pozostały otwarte, gdy aplikacja jest otwarta?

Edytować

Według strony Wiki Mozilli najlepiej użyć skryptu, aby uruchomić aplikację z argumentami. Dodanie a &na końcu skryptu zabija trwałe okno terminala. Jedyną irytacją jest teraz to, że otwiera martwe, wylogowane okno Terminala (co jest lepsze niż trwałe, ale nadal ...)

#!/bin/sh
/Applications/Firefox.app/Contents/MacOS/firefox -P default -no-remote &

Oto moje najlepsze rozwiązanie: utwórz skrypt jabłkowy za pomocą:

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

I zapisz jako aplikację .

Możesz umieścić dowolną aplikację z dowolnymi argumentami w pierwszej części. Część po &potrzebie zabicia tego, co nazwałeś swoim skryptem. Zobaczysz, że aplikacja skryptowa miga w doku, ale potem zniknie.

Uwaga: skrypt nie będzie działał poprawnie po uruchomieniu z edytora skryptów, tylko po uruchomieniu z utworzonej aplikacji skryptowej.

Począwszy od wersji OS X 10.6.2, polecenie open może przekazywać argumenty do aplikacji, którą otwiera za pomocą flagi --args. AppleScript do użycia wygląda następująco:

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

To powinno dać ci wszystkie pożądane zachowania.

Otwórz Automator i utwórz aplikację za pomocą jednej akcji Uruchom skrypt powłoki :

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

Ta aplikacja uruchomi Firefoksa i natychmiast zakończy działanie, pozostawiając tylko Firefox działający.

Możesz też utworzyć aplikację za pomocą edytora AppleScript 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 terminalu, ani aplikacji skryptowej przez dłużej niż sekundę. Korzystając z Automatora, możesz nawet utworzyć usługę, jeśli tak wybierzesz.

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

Prawdopodobnie lepiej jest użyć „identyfikatora pakietu” niż bezwzględnej ścieżki do pliku wykonywalnego:

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

Lub w skrypcie Apple:

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

To, czego jeszcze nie wymyśliłem, to jak otworzyć nową instancję / okno z innym profilem, gdy pierwszy jest już otwarty. (Jeśli uruchomię powyżej AppleScript, a następnie inny z „Profilem 2”, to Chrome nadal po prostu otworzy kolejne okno jako „Profil 1”). :(

W tym scenariuszu nie jest konieczne (jak sugerują inne odpowiedzi) użycie killall (lub podobnego), aby zabić nadrzędny proces aplikacji AppleScript („aplet”). Może nawet mieć niepożądane skutki uboczne, jeśli nazwa / wzorzec podany dla killall pasuje więcej niż tylko proces apletu nadrzędnego (np. Inne, jednocześnie uruchomione aplikacje AppleScript (jeśli używasz „apletu” jako wzorca)).

Coś w tym rodzaju kill $PPIDmoże być bardziej rozsądne, ale nie możemy zakładać, że aplet aplikacji AppleScript jest zawsze bezpośrednim rodzicem powłoki uruchamianej przez skrypt do shell . Na szczęście istnieje całkowicie rozsądny sposób na robienie tego, czego potrzebujesz.

Na TN2065 (w części „Chcę uruchomić proces serwera w tle; jak sprawić, aby skrypt powłoki nie czekał, aż polecenie się zakończy?”), Właściwą metodą jest przekierowanie stdout i stderr i uruchomienie powłoki przez program w tle .

Użyj Script Editor, aby zapisać następujący program jako aplikację AppleScript:

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

_{(podziały wiersza funkcjonalny dodany do utrzymania go „wąski”; usunąć ¬i \\i umieścić to wszystko na jednej długiej linii, jeśli chcesz)}

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

Przekierowanie jest wymagane, ponieważ skrypt powłoki nie tylko czeka na natychmiastowe zamknięcie swojego potomka (powłoki), ale także czeka (wszystkie wystąpienia) zapisywalnych końców potoków, które tworzy, na zamknięcie stdout i stderr powłoki . Stdout i stderr powłoki ( wykonaj potoki skryptu powłoki ) są dziedziczone przez programy, które działa bez przekierowania (nawet te działające w tle z &); przekierowanie zapewnia, że ​​powłoka jest ostatnią utrzymującą zapisywalne końce rur. Zatem skrypt do shell powróci natychmiast po wyjściu z powłoki, umożliwiając zamknięcie samej aplikacji AppleScript (ponieważ skrypt do shell jest ostatnim wyrażeniem w programie AppleScript).

Inne odpowiedzi, które używają open inside, działają w skrypcie powłoki, ponieważ open (w rzeczywistości LaunchServices) wykonuje równoważną pracę polegającą na tworzeniu tła wynikowego programu i wysyłaniu stdout i stderr w inne miejsce.

AppleScript

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

Dwa punkty.

1. Spacja jest usuwana przez odwrotny ukośnik, który jest ponownie uciekany przez odwrotny ukośnik
2. aplet killall może powodować problemy, ponieważ mogą działać inne aplety
3. Zapisz jako program

Jednak działa dobrze w 10.6.5

Poniższe informacje powinny umożliwić określenie argumentów wiersza polecenia dla samej aplikacji .app:

Kliknij prawym przyciskiem myszy pakiet .app, wybierz „Pokaż zawartość pakietu”, przejdź do Info.plist, kliknij dwukrotnie, znajdź klucz Args, edytuj.

W tej chwili nie mam pod ręką komputera z systemem OS X, więc nie mogę sprawdzić, czy możesz to zrobić z aliasem (jeśli chcesz zachować oryginalny plik .app bez argumentów itp.).

Zawiń aplikację w programie uruchamiającym AppleScript.

Oto kroki.

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

   set pathToApp to (POSIX path of (path to me)) & "Firefox 3.app"
   do shell script "open -a \"" & pathToApp & "\" --args -P default -no-remote"
   

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

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

   Wynik: / Aplikacje / Firefox 3 launcher.app/Firefox 3.app

4. Możesz teraz otworzyć program uruchamiający aplikacje.

Uwagi:

• Automatyczne aktualizacje zapakowanej aplikacji powinny działać w większości przypadków.
• Powinno być możliwe automatyczne przekierowanie do programu uruchamiającego dowolnego przeciągnięcia i upuszczenia do zapakowanej aplikacji (z nieco większą ilością skryptów).
• Program uruchamiający automatycznie kończy pracę po uruchomieniu opakowanej aplikacji.
• Zaletą tej metody jest to, że istnieje niewielkie ryzyko bezpośredniego otwarcia opakowanej aplikacji.

Dlaczego nie używasz:

#!/bin/sh
open /Applications/Firefox.app

Proste, ale działa.

openKomenda ma opcjonalny --argsargument, że jego wartość będzie przekazywana do otwartych aplikacji jako argumenty. Na przykład:

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