Qual é o significado de um ponto antes de um comando no shell?

53

Ao seguir o tutorial de depuração do eclipse para Android, encontro os seguintes comandos.

cd /path/to/android/root 
. build/envsetup.sh 
lunch 1    
make       
emulator

Meu problema é o que o ponto antes de build/envsetup.sh significa?

    
por Jichao 09.02.2014 / 05:49

3 respostas

59

Um ponto nesse contexto significa "originar" o conteúdo desse arquivo no shell atual. Com source sendo um comando interno do shell. E source e o operador ponto sendo sinônimos.

Exemplo

Digamos que eu tenha o seguinte conteúdo em um arquivo sample.sh .

$ cat sample.sh 
echo "hi"
echo "bye?"

Agora, quando eu faço isso:

$ . sample.sh 
hi
bye?
$

Arquivos como este geralmente são usados para incorporar comandos de configuração, como adicionar itens às variáveis de ambiente.

Exemplos

Digamos que eu tenha esses comandos em outro arquivo, addvars.sh .

$ cat addvars.sh 
export VAR1="some var1 string"
export VAR2="some var2 string"

Note que não tenho nenhuma variável no ambiente atual do meu shell.

$ env | grep VAR
$

Agora, quando eu source este arquivo:

$ . addvars.sh 
$

OK, parece que não fez nada, mas quando verificamos novamente as variáveis env :

$ env | grep VAR
VAR1=some var1 string
VAR2=some var2 string
    
por 09.02.2014 / 06:01
53

Para adicionar a resposta do slm:

Existem duas maneiras de executar um script de shell. Uma delas é executar o script em um processo separado, o que significa que qualquer coisa sobre o ambiente do shell (estado da memória) será revertida para o estado do shell "pai" antes de executar o processo shell "filho".

Por exemplo, o diretório de trabalho atual (o local no sistema de arquivos em que se está) é determinado por processo. Então, vamos ter um script assim:

#!/bin/bash
cd ~
cd ..
pwd

Então, vamos chamar esse script, oh, foo . E vamos executar este script da seguinte forma: ./foo

Nós veremos o seguinte:

/home

(Aviso de isenção padrão de que há um grande número de distribuições de clones do Linux e de outros UNIX, algumas das quais não colocam diretórios do usuário em /home . Ou, como costumavamos dizer "Sua milhagem pode variar")

Agora, depois de executar este script, vamos digitar este comando

pwd

Para ver em qual diretório estamos. Veremos algo assim:

/home/username

O motivo é que, novamente, o shell script que nós rodamos tinha seu próprio ambiente (incluindo seu próprio diretório onde os comandos estavam sendo executados), e esse ambiente foi embora assim que o script terminou de rodar.

Agora, vamos executar o script foo como este

. ./foo

Ou, de forma equivalente:

source ./foo

Se fizermos um pwd , veremos isso:

/home

O motivo é: O fornecimento de um script não chama um processo separado. É como digitar todos os comandos do processo pai manualmente; seu ambiente é preservado após o script terminar.

Deixe-me apresentar um exemplo mais simples. Vamos ter um script assim:

#!/bin/bash
exit

Vamos chamar de foo . Vamos nos certificar de que podemos executá-lo: chmod 755 foo . Então, vamos rodar assim:

./foo

Nada acontece. No entanto, por outro lado, se fizermos isso:

. ./foo

Ou isto:

source ./foo

Nós nos desconectamos.

    
por 09.02.2014 / 06:45
5

O período (ponto) é curto para o bash criado em source . Ele lerá e executará comandos de um arquivo no ambiente atual e retornará o status de saída do último comando executado. Os arquivos podem estar no diretório atual ou em qualquer lugar no PATH . Não precisa ser executável.

    
por 03.05.2015 / 15:44

Tags