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

Quando o shell interativo atual for bash, e você executar um script sem #!-line, basho script será executado. O processo aparecerá na ps axsaída como apenas 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

Relacionado:

• Qual interpretador de shell executa um script sem shebang?

As seções relevantes formam o bashmanual:

Se essa execução falhar porque o arquivo não está em formato executável e o arquivo não é um diretório, supõe-se que seja um script de shell , um arquivo que contém 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 invocado 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 que começa com #!, o restante da primeira linha especifica um interpretador para o programa. O shell executa o interpretador especificado em sistemas operacionais que não lidam com esse formato executável. [...]

Isso significa que rodar ./foo.shna linha de comando, quando foo.shnão tem #!-line, é o mesmo que rodar os comandos no arquivo em um subshell, ou seja, como

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

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

$ /bin/bash foo.sh

Quando um script de shell começa com #!, 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 personagens #!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.) não vou mencionar). A execvechamada do sistema substitui o código do processo atualmente em execução; há uma chamada de sistema separada forkpara criar um novo processo.

Para fazer isso, o kernel tem que suportar o formato do arquivo executável. Este arquivo deve conter código de máquina, organizado de forma que o kernel entenda. 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 com #!, 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 discutirei aqui ). Quando o kernel é instruído a executar o arquivo /my/scripte 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/scripté um arquivo de script que deve ser executado.

E se um arquivo não contiver código nativo em um formato que o kernel entenda e não começar com um shebang? Bem, então 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 analisa o conteúdo do arquivo e verifica se ele se parece com um script de shell. Se o shell achar que o arquivo se parece com um script de shell, ele o executa sozinho. Os detalhes de como ele faz isso dependem do shell. Você pode ver um pouco do que está acontecendo adicionando ps $$em seu script e muito mais observando o processo strace -p1234 -f -eprocessonde 1234 é o PID do shell.

No bash, esse mecanismo de fallback é implementado chamando, forkmas não execve. O processo filho bash 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 de código bash original e os argumentos de linha de comando originais passados ​​quando você invocou o bash originalmente. 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, por outro lado, reage ENOEXECchamando /bin/shcom o caminho para o script passado como argumento. Em outras palavras, quando você executa um script shebangless do traço, ele se comporta como se o script tivesse uma linha shebang com #!/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 bifurcado do seu shell atual.

Você deve primeiro executar echo $$e, em seguida, dar uma olhada em um shell que tenha o id do processo do seu shell como id do processo pai.