"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 oPATH
. Mas mesmo que sintaticamente pareça o mesmo, ele se comportará de maneira diferente. Comoread
definirá uma variável destinada a ser usada pelos comandos a seguir,read
tem que acontecer no processo atual sem nenhuma chamadafork
. (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. Chamarfork
é um pouco caro.) - Você pode estar obtendo comandos do shell usando
. file
ousource file
. Nesse caso,file
não é um script, mas é um pouco semelhante. Todos os comandos emfile
serão invocados pelo shell atual sem primeiro chamarfork
. (Mas é claro que os comandos dentro defile
poderiam acionarfork
de chamadas). Nesse caso, qualquer#!
linha emfile
seria ignorada e quaisquer variáveis definidas porfile
estariam disponíveis para seu shell atual.