Por que "ps ax" não encontra um script bash em execução sem o cabeçalho "#!"?

Quando executo esse script, pretendia ser executado até ser morto ...

# foo.sh

while true; do sleep 1; done

... Não consigo encontrá-lo usando ps ax:

>./foo.sh

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

... mas se eu apenas adicionar o #!cabeçalho " " comum ao script ...

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

while true; do sleep 1; done

... então o script se torna localizável pelo mesmo pscomando ...

>./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

Porque isto é assim?
Esta pode ser uma pergunta relacionada: " #" pensei que era apenas um prefixo de comentário e, se for, " #! /usr/bin/bash" nada mais é do que um comentário. Mas " #!" carrega algum significado maior do que apenas um comentário?

Quando o shell interativo atual estiver bashe você executar um script sem #!linha, basho script será executado. O processo aparecerá na ps axsaída como justo bash.

$ cat foo.sh
# foo.sh

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

$ ./foo.sh
55411

Em outro terminal:

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

Palavras-chave:

• Qual interpretador de shell executa um script sem shebang?

As seções relevantes formam o bashmanual:

Se esta execução falhar porque o arquivo não está no formato executável e o arquivo não é um diretório, é considerado um script de shell , um arquivo contendo comandos de shell. Um subshell é gerado para executá-lo. Esse subshell se reinicializa, de modo que o efeito é como se um novo shell tivesse sido chamado para manipular o script , com a exceção de que os locais dos comandos lembrados pelo pai (veja o hash abaixo em SHELL BUILTIN COMMANDS) são retidos pelo filho.

Se o programa for um arquivo começando com #!, o restante da primeira linha especificará um intérprete para o programa. O shell executa o intérprete especificado em sistemas operacionais que não manipulam esse formato executável. [...]

Isso significa que executar ./foo.shna linha de comando, quando foo.shnão possui uma #!linha, é o mesmo que executar os comandos no arquivo em uma subshell, ou seja, como

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

Com uma #!linha adequada apontando para /bin/bash, por exemplo , é como fazer

$ /bin/bash foo.sh

Quando um script de shell começa #!, essa primeira linha é um comentário no que diz respeito ao shell. No entanto, os dois primeiros caracteres são significativos para outra parte do sistema: o kernel. Os dois caracteres #!são chamados de shebang . Para entender o papel do shebang, você precisa entender como um programa é executado.

A execução de um programa a partir de um arquivo requer ação do kernel. Isso é feito como parte da execvechamada do sistema. O kernel precisa verificar as permissões do arquivo, liberar os recursos (memória, etc.) associados ao arquivo executável atualmente em execução no processo de chamada, alocar recursos para o novo arquivo executável e transferir o controle para o novo programa (e mais coisas que Eu não vou mencionar). A execvechamada do sistema substitui o código do processo em execução no momento; há uma chamada de sistema separada forkpara criar um novo processo.

Para fazer isso, o kernel precisa suportar o formato do arquivo executável. Este arquivo deve conter o código da máquina, organizado da maneira que o kernel entende. Um script de shell não contém código de máquina, portanto, não pode ser executado dessa maneira.

O mecanismo shebang permite que o kernel adie a tarefa de interpretar o código para outro programa. Quando o kernel vê que o arquivo executável começa #!, ele lê os próximos caracteres e interpreta a primeira linha do arquivo (menos o #!espaço inicial e opcional) como um caminho para outro arquivo (mais argumentos, que não serão discutidos aqui) ) Quando o kernel é dito para executar o arquivo /my/script, e ele vê que o arquivo começa com a linha #!/some/interpreter, o kernel executa /some/interpretercom o argumento /my/script. Cabe então /some/interpreterdecidir que /my/scriptesse arquivo de script deve ser executado.

E se um arquivo não contiver código nativo em um formato que o kernel compreenda e não iniciar com um shebang? Bem, o arquivo não é executável e a execvechamada do sistema falha com o código de erro ENOEXEC(erro de formato executável).

Este pode ser o fim da história, mas a maioria dos shells implementa um recurso de fallback. Se o kernel retornar ENOEXEC, o shell examinará o conteúdo do arquivo e verificará se ele se parece com um script de shell. Se o shell achar que o arquivo se parece com um script de shell, ele será executado sozinho. Os detalhes de como isso acontece depende do shell. Você pode ver um pouco do que está acontecendo adicionando ps $$no seu script e muito mais assistindo ao processo em strace -p1234 -f -eprocessque 1234 é o PID do shell.

No bash, esse mecanismo de fallback é implementado chamando fork mas não execve. O processo bash filho limpa seu estado interno sozinho e abre o novo arquivo de script para executá-lo. Portanto, o processo que executa o script ainda está usando a imagem do código do bash original e os argumentos da linha de comando originais passados ​​quando você chamou o bash originalmente. O ATT ksh se comporta da mesma maneira.

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

Dash, ao contrário, reage ENOEXECchamando /bin/shcom o caminho para o script passado como argumento. Em outras palavras, quando você executa um script sem barra a partir do traço, ele se comporta como se o script tivesse uma linha shebang #!/bin/sh. Mksh e zsh se comportam da mesma maneira.

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

No primeiro caso, o script é executado por um filho extraído do seu shell atual.

Você deve primeiro executar echo $$e, em seguida, examinar um shell que tenha o ID do processo do seu shell como ID do processo pai.