Czy w najprostszej postaci programy po prostu uruchamiają polecenia terminala?

Powiedzmy na przykład, że program pozwala mi wybrać jeden folder i skopiować go do innej lokalizacji, czy na bardzo podstawowym poziomie jest to, że aplikacja uruchamia polecenia, które mógłbym uruchomić w terminalu, czy używa jakiegoś wewnętrznego interfejsu API systemu operacyjnego, aby to przenieść?

Proszę oszczędzić mi wszelkich błędnych odpowiedzi; Jestem tylko ciekawy i całkowicie świadomy, że można to postrzegać jako pytanie, które zadałby 13-latek.

Pod względem koncepcyjnym zawsze używa OS API - pytanie dotyczy tylko tego, w jaki sposób. Istnieją zasadniczo trzy opcje.

1. za pomocą bezpośredniego interfejsu API systemu operacyjnego (wywołania systemowe). W twoim przykładzie zadanie jest dość zaangażowane: pobierz listę elementów w folderze, sprawdź typ (folder, plik ...), dla każdego z nich utwórz odpowiedni element w folderze docelowym, dla plików odczytaj zawartość z źródło, zapisz do pliku docelowego itp. Ponieważ zadanie jest tak złożone, łatwo jest coś zrobić źle, więc większość aplikacji tego uniknie.

2. użyj biblioteki (API), która upraszcza zadanie. Na przykład framework Apple Cocoa zapewnia NSFileManagerklasie copyItemAtPath:toPath:errormetodę, która wykonuje całą brudną pracę przy użyciu niskopoziomowego interfejsu API systemu operacyjnego, więc aplikacja nie musi korzystać z samego interfejsu API niskiego poziomu, ale może polegać na czymś, co wymaga mniej pracy i zawsze jest obecny w systemie. Również Apple może upewnić się, że działa dobrze.

3. użyj zewnętrznego procesu do wykonania zadania. W takim przypadku proces zewnętrzny będzie używał jednej z dwóch powyższych metod do wykonania pracy. Aplikacja musi rozpocząć taki proces, monitorować go i poczekać, aż się zakończy. Jest prawdopodobne, że taki proces można uruchomić jako narzędzie wiersza polecenia, więc prawdopodobnie będzie to polecenie, które można uruchomić w terminalu. Nie jest to gwarantowane, ale bardzo możliwe.

Większość aplikacji korzysta z opcji 2., ponieważ jest prostsza niż 1. oraz bezpieczniejsza i wydajniejsza niż 3. Aby uruchomić proces zewnętrzny, musisz go poprawnie skonfigurować i nie masz kontroli nad tym, co robi. Na przykład o wiele trudniej jest dowiedzieć się, co dokładnie poszło nie tak w przypadku awarii i trudno jest wiedzieć, co robi (np. Pokazać postęp). Dlatego w większości przypadków programiści prawdopodobnie wybiorą opcję 2, ale nie ma gwarancji. Godnym uwagi przykładem są aplikacje wykorzystujące skrypty powłoki do dostosowywania - takie jak instalatory.

Uwaga dla zaawansowanych użytkowników: możesz użyć dtracefunkcji OS X, aby dowiedzieć się, co robi konkretna aplikacja. Na przykład możesz sprawdzić wszystkie procesy, które się odradza, aby zobaczyć narzędzia, których używa (patrz execsnoop).

Obawiam się, że odpowiedź brzmi „to zależy, ale zwykle druga”. W rzeczywistości nawet jeśli program GUI uruchamia polecenia terminalu, uruchamia je, wywołując interfejs API.

Program będący po prostu listą poleceń terminalowych nazywa się skryptem powłoki. Takie programy mogą działać w systemie Mac OS X, ale muszą albo uruchomić się w oknie terminala, albo uruchomić program korzystający z GUI, jeśli chcesz zobaczyć ich wyniki. Inne programy mogą wywoływać programy wiersza poleceń za pośrednictwem wewnętrznych interfejsów API.

Podczas gdy większość pytań programistycznych jest nie na temat tej witryny, jeden przykład, który jest na ten temat, dotyczy uruchomienia Automatora.

Jedną z opcji na liście poleceń wewnętrznych, które może wywoływać program utworzony w programie Automator, jest możliwość wywołania skryptu powłoki lub listy poleceń terminalu. Ale to tylko jedna z wielu opcji dostępnych w jej wewnętrznym interfejsie API.

Jednym z wielkich pomysłów Unixa jest (było), że jeśli masz pomysł na program, najpierw napiszesz go jako skrypt powłoki - w zasadzie wywołując serię poleceń.

Następnie, jeśli program okaże się przydatny, możesz ulepszyć jego interfejs, poprosić użytkowników o przetestowanie go, a na koniec, gdy będziesz przekonany, że warto, napisz „prawdziwy” program.

Było to oczywiście przed przejęciem graficznych interfejsów użytkownika, więc „program” jest tutaj poleceniem CLI.

Nadal widzisz to podejście w niektórych nowoczesnych programach, szczególnie jeśli pokazują one informacje o systemie. Chcesz zbudować prostą aplikację do wyświetlania listy wszystkich plików w folderze? Po prostu uruchom ls -al, przeanalizuj wynik i pokaż mu tabelę. Baw się dobrze z różnymi parametrami, a masz materiał do wersji 2.0

Jedną klasą programów, które uruchamiają polecenia terminala (mimo że wszystko zaczyna się od wywołania API), są zintegrowane środowiska programistyczne, takie jak eclipse lub Xcode. Zbiór narzędzi wymaganych do opracowania programu jest zbyt duży, aby mógł być zawarty w IDE i utrzymywany w nim. Zamiast tego buduje plik makefile (rodzaj skryptu) i uruchamia go z uniksowym „make” (lub odpowiednikiem), aby przejść przez proces kompilacji, łączenia, ładowania i debugowania. Make z kolei uruchamia kompilator, konsolidator itp. Za pomocą interfejsów wiersza poleceń. Dzięki temu IDE jest względnie niezależny od zestawu narzędzi wybranego przez programistę i niewrażliwy na aktualizacje narzędzi.

Aplikacje mogą uruchamiać polecenia CLI w celu wykonania określonego zadania, a niektóre faktycznie; ale ze względu na problemy z wydajnością profesjonalni twórcy aplikacji unikają uruchamiania polecenia i raczej używają interfejsów API używanych przez polecenie do wykonania wymaganego zadania.