SSH Diferença entre ./ e sh

Question

Eu escrevi um arquivo simples "olá mundo" e tente executá-lo no servidor virtual pelo SSH.

#!/bin/bash
echo "Hello world"

Claro que dou chmod +x

Então, em um servidor, tento executá-lo pelo comando:

./file.sh

E eu tenho resposta:

-bash: ./file.sh: Permission denied

Funciona apenas quando eu inicio por comando:

sh file.sh

Em outro servidor, ambos os comandos funcionam bem ...

Então, minha pergunta é: existe algum tipo de permissão que impeça a execução com o comando ./ ?

Qual é a diferença entre os dois comandos?

    

Answer 1

O sistema de arquivos pode ser montado com noexec . Eu recriou isso no meu Debian. O comportamento se encaixa.

Quando você executa ./file.sh , ele é tratado como executável; no entanto, com /bin/bash file.sh , o executável é /bin/bash .

    

Answer 2

Este é um extrato do manual ( man sh ): -

If command line arguments besides the options have been specified, then the shell treats the first argument as the name of a file from which to read commands (a shell script), and the remaining arguments are set as the positional parameters of the shell ($1, $2, etc). Otherwise, the shell reads commands from its standard input.

Assim, em sh file.sh , o arquivo file.sh especificado se torna uma fonte de entrada para o shell, portanto, precisa ser legível, mas não precisa ser executável. O mesmo vale para o comando source ou . , portanto, o seguinte executará um arquivo não executável: -

sh ./file.sh
sh<./file.sh
. ./file.sh
source ./file.sh

Os dois últimos serão executados no shell atual, os dois primeiros em um sub-shell. Observe que sh -c ./file.sh exigirá file.sh para executável, enquanto sh -c ". ./file.sh" não precisa. Observe também que, se file.sh for executável, sua localização precisará estar em $PATH se for chamada diretamente, a menos que um caminho específico ( ./ no exemplo) seja incluído:

file.sh

No entanto, os quatro exemplos anteriores não precisam do prefixo ./ , pois o arquivo a ser lido sempre será procurado no diretório atual (embora os comandos . e source também pesquisem $PATH ).

Dois pontos finais: -

1. Os quatro exemplos funcionam apenas para arquivos de script: todos eles falharão se file.sh for um executável binário.
2. Nos quatro exemplos, o comentário #!/bin/bash é apenas um comentário: a execução sh irá lê-lo como tal e não clonará bash para executar o resto do arquivo, então, qualquer extensão bash causará erros.