Dlaczego „ps ax” nie znajduje działającego skryptu bash bez „#!” nagłówek?

Kiedy uruchamiam ten skrypt, zamierzam go uruchomić aż do zabicia ...

# foo.sh

while true; do sleep 1; done

... Nie mogę go znaleźć za pomocą ps ax:

>./foo.sh

// In a separate shell:
>ps ax | grep foo.sh
21110 pts/3    S+     0:00 grep --color=auto foo.sh

... ale jeśli po prostu dodam wspólny #!nagłówek " " do skryptu ...

#! /usr/bin/bash
# foo.sh

while true; do sleep 1; done

... wtedy skrypt można znaleźć za pomocą tego samego pspolecenia ...

>./foo.sh

// In a separate shell:
>ps ax | grep foo.sh
21319 pts/43   S+     0:00 /usr/bin/bash ./foo.sh
21324 pts/3    S+     0:00 grep --color=auto foo.sh

Dlaczego tak jest?
To może być powiązane pytanie: Myślałem, że „ #” to tylko przedrostek komentarza, a jeśli tak, to „ #! /usr/bin/bash” sam w sobie jest jedynie komentarzem. Ale czy „ #!” ma jakieś znaczenie większe niż tylko komentarz?

Gdy bieżąca interaktywna powłoka jest bashuruchomiona, a ty uruchomisz skrypt bez #!-line, wtedy bashuruchom skrypt. Proces pojawi się na ps axwyjściu jako sprawiedliwy bash.

$ cat foo.sh
# foo.sh

echo "$BASHPID"
while true; do sleep 1; done

$ ./foo.sh
55411

W innym terminalu:

$ ps -p 55411
  PID TT  STAT       TIME COMMAND
55411 p2  SN+     0:00.07 bash

Związane z:

• Który interpreter powłoki uruchamia skrypt bez shebang?

Odpowiednie sekcje tworzą bashinstrukcję:

Jeśli wykonanie nie powiedzie się, ponieważ plik nie jest w formacie wykonywalnym, a plik nie jest katalogiem, zakłada się , że jest to skrypt powłoki , plik zawierający polecenia powłoki. Powstaje podpowłoka, aby ją wykonać. Ta podpowłoka inicjuje się ponownie, tak że efekt jest taki, jakby wywołano nową powłokę do obsługi skryptu , z tym wyjątkiem, że lokalizacje poleceń zapamiętanych przez rodzica (patrz skrót poniżej WBUDOWANE POLECENIA POWŁOKI) są zachowywane przez dziecko.

Jeśli program jest plikiem zaczynającym się od #!, reszta pierwszego wiersza określa interpreter dla programu. Powłoka wykonuje określony interpreter w systemach operacyjnych, które same nie obsługują tego formatu wykonywalnego. [...]

Oznacza to, że uruchamianie ./foo.shw wierszu poleceń, gdy foo.shnie ma #!-linii, jest takie samo, jak uruchamianie poleceń w pliku w podpowłoce, tj.

$ ( echo "$BASHPID"; while true; do sleep 1; done )

Przy odpowiedniej linii #!wskazującej na np /bin/bash. Robi to tak samo

$ /bin/bash foo.sh

Kiedy zaczyna się skrypt powłoki #!, ten pierwszy wiersz jest komentarzem w odniesieniu do powłoki. Jednak pierwsze dwa znaki mają znaczenie dla innej części systemu: jądra. Dwie postacie #!nazywane są shebang . Aby zrozumieć rolę shebang, musisz zrozumieć, jak program jest wykonywany.

Wykonywanie programu z pliku wymaga działania z jądra. Odbywa się to w ramach execvewywołania systemowego. Jądro musi zweryfikować uprawnienia do pliku, zwolnić zasoby (pamięć itp.) Związane z plikiem wykonywalnym aktualnie uruchomionym w procesie wywoływania, przydzielić zasoby dla nowego pliku wykonywalnego i przenieść kontrolę do nowego programu (i więcej rzeczy, które Nie wspomnę). execveWywołanie systemowe zastępuje kod aktualnie uruchomionego procesu; istnieje osobne wywołanie systemowe, forkaby utworzyć nowy proces.

Aby to zrobić, jądro musi obsługiwać format pliku wykonywalnego. Ten plik musi zawierać kod maszynowy zorganizowany w sposób zrozumiały dla jądra. Skrypt powłoki nie zawiera kodu maszynowego, więc nie można go wykonać w ten sposób.

Mechanizm shebang pozwala jądru na odroczenie zadania interpretacji kodu do innego programu. Kiedy jądro widzi, że zaczyna się plik wykonywalny #!, odczytuje kilka kolejnych znaków i interpretuje pierwszy wiersz pliku (minus #!spację wiodącą i opcjonalną) jako ścieżkę do innego pliku (plus argumenty, których nie będę tutaj omawiać ). Kiedy jądro ma wykonać plik /my/scripti widzi, że plik zaczyna się od linii #!/some/interpreter, jądro wykonuje się /some/interpreterz argumentem /my/script. Następnie /some/interpreternależy zdecydować, że /my/scriptjest to plik skryptu, który powinien wykonać.

Co jeśli plik nie zawiera natywnego kodu w formacie zrozumiałym dla jądra i nie zaczyna się od shebang? Cóż, wtedy plik nie jest wykonywalny, a execvewywołanie systemowe kończy się niepowodzeniem z kodem błędu ENOEXEC(błąd formatu wykonywalnego).

To może być koniec historii, ale większość pocisków implementuje funkcję awaryjną. Jeśli jądro powróci ENOEXEC, powłoka sprawdza zawartość pliku i sprawdza, czy wygląda jak skrypt powłoki. Jeśli powłoka uważa, że ​​plik wygląda jak skrypt powłoki, wykonuje go samodzielnie. Szczegóły tego, jak to robi, zależą od powłoki. Możesz zobaczyć, co się dzieje, dodając ps $$do skryptu, a więcej, obserwując proces, w strace -p1234 -f -eprocessktórym 1234 to PID powłoki.

W bash ten mechanizm rezerwowy jest realizowany przez wywołanie, forkale nie execve. Proces potomnego bash sam usuwa stan wewnętrzny i otwiera nowy plik skryptu, aby go uruchomić. Dlatego proces, który uruchamia skrypt, nadal używa oryginalnego obrazu kodu bash, a oryginalne argumenty wiersza poleceń przekazane przy pierwszym wywołaniu bash. ATT ksh zachowuje się w ten sam sposób.

% bash --norc
bash-4.3$ ./foo.sh 
  PID TTY      STAT   TIME COMMAND
21913 pts/2    S+     0:00 bash --norc

Dash natomiast reaguje na ENOEXECwywołanie /bin/shze ścieżką do skryptu przekazaną jako argument. Innymi słowy, wykonanie skryptu bez kreski z kreski zachowuje się tak, jakby skrypt zawierał linię shebang #!/bin/sh. Mksh i zsh zachowują się w ten sam sposób.

% dash
$ ./foo.sh
  PID TTY      STAT   TIME COMMAND
21427 pts/2    S+     0:00 /bin/sh ./foo.sh

W pierwszym przypadku skrypt jest uruchamiany przez rozwidlone dziecko z bieżącej powłoki.

Najpierw powinieneś uruchomić, echo $$a następnie spojrzeć na powłokę, która ma identyfikator procesu powłoki jako identyfikator procesu nadrzędnego.