Qual é a diferença entre executar "bash script.sh" e "./script.sh"?

42

Se script.sh é apenas algo típico como

#!/bin/bash
echo "Hello World!"

Existe uma maneira preferida de executar o script? Eu acho que você primeiro tem que chmod para que se torne executável?

bash shell-script executable

— user72136
fonte

56

Para o seu script específico, qualquer uma das maneiras funcionará, exceto que ./script.shrequer execução e bits legíveis, enquanto bash script.shrequer apenas bits legíveis.

O motivo da diferença dos requisitos de permissão está na maneira como o programa que interpreta o seu script é carregado:

./script.sh faz seu shell executar o arquivo como se fosse um executável regular.

O shell se bifurca e usa uma chamada do sistema (por exemplo execve) para fazer o sistema operacional executar o arquivo no processo bifurcado. O sistema operacional verificará as permissões do arquivo (portanto, o bit de execução precisa ser definido) e encaminhará a solicitação ao carregador do programa , que analisa o arquivo e determina como executá-lo. No Linux, os executáveis compilados começam com um número mágico ELF , enquanto os scripts começam com um #!( hashbang ). Um cabeçalho hashbang significa que o arquivo é um script e precisa ser interpretado pelo programa especificado após o hashbang. Isso permite que um script em si diga ao sistema como interpretá-lo.

Com o seu script, o carregador de programas será executado /bin/bashe transmitido ./script.sh como o argumento da linha de comandos.

bash script.shfaz seu shell rodar bashe passar script.shcomo o argumento da linha de comando

Portanto, o sistema operacional será carregado bash(nem mesmo olhando script.sh, porque é apenas um argumento da linha de comando). O bashprocesso criado interpretará o script.shporque é passado como o argumento da linha de comando. Como script.shé lido apenas bashcomo um arquivo regular, o bit de execução não é necessário.

Eu recomendo o uso ./script.sh, porque você pode não saber qual intérprete o script está exigindo. Então deixe o carregador do programa determinar isso para você.

— SkyDan
fonte

3

Se o bit executável não está definida, você também pode executar o script fazendo "./script.sh."

— Dog Eat World Cat

1

@ Dog Você está correto. O ponto é um atalho para o comando interno 'source', que executa o script no processo atual do bash. Portanto, apenas o bit legível é necessário.

— SkyDan

5

@Dogeatcatworld enquanto isso é verdade, correr . ./script.shnão é a mesma coisa que bash script.sh(ou ./script.shConsidere o script. #!/usr/bin/python -V<Newline> print test.

— Casey

12

Cuidado que o fornecimento de um script pode resultar na contaminação da sessão interativa. Por exemplo, se um script alterar a variável de ambiente PATH, essa alteração afetará os comandos executados após a origem. Essa abordagem deve ser realmente reservada para situações nas quais você depende dos efeitos colaterais (scripts de configuração do ambiente e similares). Para outras situações em que você não pode alterar as permissões, executar o comando na linha shebang, seguido pelo nome do script, é a abordagem mais segura.

— ctt

6

Observe que, se você cria um script no diretório atual, não precisa usar ./ ; apenas diga . script.sh. Mas concordo com as pessoas que desencorajam o uso do .comando em scripts que não deveriam ser invocados dessa maneira. Estou surpreso que ninguém tenha mencionado que, se o script contiver exitcomandos e você o originar, ele poderá desconectá-lo. Um problema menos grave seria se o script fizesse a cd, pois isso também afetaria o shell pai (interativo).

— Scott

18

bash script.shchama o script diretamente usando o bash.
./script.shestá usando o shebang #!/bin/bashpara determinar como executar.

Se você realmente quer saber, qual binário é executado, se você fizer um, bash script.shpoderá descobrir which bash.

Portanto, no seu exemplo, não faz diferença. Sim, você deve chmod +x script.shpoder executá-lo diretamente via ./script.sh.

— xx4h
fonte

2

Bem, não faz diferença supor que /bin/bashseja o primeiro bashno seu $PATH.

— CJM

Você está certo. E a coisa toda #!/bin/bashsó funciona se houver uma/bin/bash

— xx4h

O Bash (versão 4.2.37) no meu sistema executa scripts mesmo sem o bit de execução definido. Por que você diz que o bit de execução é necessário?

— 11119 SkyDan

Sim, o bit de execução é necessário apenas invocando via ./script.sh.

— Xx4h

4

Crie um arquivo Delete_Self.sh assim:

 #!/bin/rm

 echo I am still here!

Execute este script como sh Delete_Self.shvocê verá "Eu ainda estou aqui!" ecoou de volta.

Torne-o executável e execute-o como ./Delete_Self.shvocê verá que nada é repetido, enquanto o arquivo em Delete_Self.shsi desapareceu.

Então a diferença é que:

bash script.shirá ignorar o #! linha, porque o bash é especificado como o programa para executar o script.sh.
./script.shvai ler o #! linha para determinar o programa a ser executado script.sh.

— David
fonte

+1 para o bom exemplo

— ThisaruG

1

Além das outras respostas, é útil saber a diferença entre executar um script via ./script.sh(i) e fonte ./script.sh(ii) - A versão (i) cria um novo shell para executar o comando, enquanto (ii) o executa no shell atual - que pode ser obrigatório se o executável alterar variáveis de ambiente que precisam ser preservadas após a saída do executável. Por exemplo, para ativar um ambiente python conda, o seguinte deve ser usado:

source activate my_env

NB Outra alternativa a sourceque você pode encontrar é o .embutido, ou seja,

. activate my_env

— einonm
fonte