subshell não é criado se executar comandos sem um caminho?

Question

Estou lendo o livro " Linux Command Line e Shell Scripting Bible " 3ª edição. Na página 279, aqui cito:

"Command substitution creates what's called a subshell to run the enclosed command. A subshell is a separate child shell generated from the shell that's running the script. Because of that, any variables you create in the script aren't available to the subshell command.

Subshells are also created if you run a command from the command prompt using the ./ path, but they aren't created if you just run the command without a path."

A última frase me confunde. Eu testei com um script simples que exporta algumas variáveis; as variáveis não durariam após o script existir, no entanto, o script é invocado, de ./ path, ou coloca o script em /usr/bin e o executa sem um caminho. Parece-me que não há diferença como é invocado em relação à subcamada.

O que eu senti falta?

    

Answer 1

"Command substitution creates what's called a subshell to run the enclosed command. A subshell is a separate child shell generated from the shell that's running the script.

Isto está falando de construções como:

echo "$(date) 'uname -r'"

Neste exemplo, estou invocando dois subshells usando as duas diferentes notações suportadas para subshells. O primeiro subshell executa o comando date e o segundo subshell executa o comando uname . O comando echo é executado pelo shell original após o encerramento de ambos os subshells.

Because of that, any variables you create in the script aren't available to the subshell command.

Aqui, o autor retrocedeu. Variáveis criadas antes de invocar o subshell estão disponíveis para o subshell. Variáveis criadas dentro do subshell só estão disponíveis para o subshell e irão embora assim que a subshell terminar.

Subshells are also created if you run a command from the command prompt using the ./ path, but they aren't created if you just run the command without a path."

Não está claro o que o autor está tentando dizer aqui. Se você invocar um comando externo, o seguinte acontecerá, independentemente de ser invocado com ou sem um caminho:

• O shell fork s para criar um novo processo.
• O processo filho recém-criado executa qualquer redirecionamento de E / S que você tenha especificado.
• O processo filho executa o comando externo no ponto em que o processo deixa de ser um shell e se torna qualquer que seja o programa externo. (Que, claro, poderia ser um script de shell).

É um novo processo, portanto, quaisquer variáveis definidas pelo comando externo estarão indisponíveis para o processo pai, da mesma forma que seriam se tivessem sido uma subcamada.

O autor pode estar se referindo a um dos três cenários a seguir:

• O comando externo é um script formatado incorretamente, caso em que o shell de chamada pode estar trabalhando em torno da formatação incorreta, fazendo uma suposição sobre qual shell usar para interpretar o script. (Esse cenário é tão imprevisível que eu não recomendo confiar nele. A maneira correta de encontrar o interpretador é ter uma linha #! no início do script.)
• Você pode estar invocando um comando interno, como read , que se parece sintaticamente com um comando externo encontrado pesquisando o PATH . Mas mesmo que sintaticamente pareça o mesmo, ele se comportará de maneira diferente. Como read definirá uma variável destinada a ser usada pelos comandos a seguir, read tem que acontecer no processo atual sem nenhuma chamada fork . (Mesmo os comandos internos que podem ser invocados com segurança como um subprocesso são melhor feitos no processo atual por motivos de desempenho. Chamar fork é um pouco caro.)
• Você pode estar obtendo comandos do shell usando . file ou source file . Nesse caso, file não é um script, mas é um pouco semelhante. Todos os comandos em file serão invocados pelo shell atual sem primeiro chamar fork . (Mas é claro que os comandos dentro de file poderiam acionar fork de chamadas). Nesse caso, qualquer #! linha em file seria ignorada e quaisquer variáveis definidas por file estariam disponíveis para seu shell atual.