Diferentes maneiras de executar binários e scripts

7

Estou usando o Linux há algum tempo e tenho procurado uma visão completa disso, mas não encontrei nenhum.

Eu simplesmente não aceito todas as maneiras diferentes de executar scripts e binários - é uma grande confusão para mim e eu tenho que usar tentativa e erro para determinar o que devo usar. Para um arquivo que é um script ou um binário <script/binary> , posso propor as seguintes alternativas:

<script/binary>
. <script/binary>
./<script/binary>
source <script/binary>
sh <script/binary>

(Há mais?)

Alguém pode fornecer uma visão geral completa de quais comandos funcionam com quais tipos de arquivos e qual é a diferença quando há várias opções?

Obrigado.

    
por Carl 16.07.2012 / 12:40

3 respostas

3

Os seguintes comandos são os mesmos, um componente de ponto significa "diretório atual". Para permitir a execução, os arquivos precisam ter permissões executáveis:

path/to/binary
./path/to/binary

Observe que, se um caminho não contiver uma barra, ele será tratado como um comando (um shell interno ou um programa pesquisado na variável de ambiente $PATH ).

Os itens a seguir são quase os mesmos, eles executam um script de shell (não um binário!) no ambiente de shell atual. Uma pequena diferença entre as duas linhas é descrita nesta pergunta Unix.SE .

. path/to/script
source path/to/script

Finalmente, você mencionou sh script . Novamente, isso funciona apenas para scripts de shell e não para binários. Você está basicamente executando o programa sh com o nome do script como argumento. No caso de sh , ele apenas trata esse argumento como shell script e o executa.

Para respostas restritas a shellscripts, consulte Diferentes maneiras de executar um script de shell .

    
por Lekensteyn 16.07.2012 / 13:07
2

Aqui está uma lista rápida de comandos. Note, quando eu menciono PATH, quero dizer os diretórios contendo programas que o sistema conhece; você encontrará aqueles com echo $PATH e será algo como: /home/mike/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Scripts

  • Para executar um script no diretório de trabalho atual, use ./myscript.sh
  • Para executar um script em outro arquivo, use (se estiver no diretório de trabalho atual), ./myscript.sh textfile.txt
  • Os scripts também podem ser executados com argumentos; como explicado em Rute (p. 68): myfile.sh dogs cats birds produzirá The first argument is: dogs, second argument is: cats, third argument is: birds porque o conteúdo deste script após o shebang é: echo "The first argument is: , second argument is: , third argument is: "

  • Para executar um script em outro diretório, use ~/Scripts/dogs.sh

  • Para executar um script que o sistema conheça porque está na sua pasta bin no seu diretório pessoal (apenas crie-o se ele não estiver lá, pois ele será automaticamente adicionado ao seu PATH), use apenas scriptname
  • Para executar um script que você instalou, use apenas o nome dele, porque ele será conhecido pelo sistema: por exemplo, get_iplayer

Binários

  • Para executar um binário que o sistema conhece porque está em $ PATH, use o nome do programa e quaisquer parâmetros, por exemplo, vlc <stream url to open>
  • Para testar um binário que você compilou antes de instalar em / usr / local / bin ou para manter um programa independente longe do sistema, use ~/<folder>/app/myprog
por user76204 16.07.2012 / 13:34
2

Obrigado por toda a entrada. Tentarei responder à minha pergunta agora e fornecer um guia completo sobre as diferentes possibilidades de executar scripts e binários. Por favor, edite e comente e poderemos encontrar algo completo e correto. Aqui está minha sugestão:

Primeiramente, dois pontos a declarar:

  • O Linux faz uma distinção entre um comando e um caminho . Um comando é apenas digitado como está no prompt, e irá executar um built-in ou fará com que o Linux procure por um binário ou um script correspondente no $ PATH.

  • Para o Linux interpretar algo como um caminho, ele precisa conter pelo menos uma barra (/). Por exemplo. em ./myScript , ./ pode parecer bastante redundante - está lá apenas para fazer o Linux interpretá-lo como um caminho em vez de um comando.

Então, as opções para executar um binário ou um script:

Execução de um binário binary :

$ binary          # when 'binary' is on the PATH, or is a built-in
$ ./binary        # when 'binary' is not on the path but in the current directory
$ /home/me/binary # when 'binary' is not on the PATH, and not in the current dir

Execução de um script script :

O arquivo terá que ter permissões de execução, salvo indicação em contrário.

$ script        # execute a script that is on PATH. Will be executed in a new shell.
                # The interpreter to use is determined by the she-bang in the file.
$ ./script      # execute a script that is in the current dir. Otherwise as above.
$ /a/dir/script # when the script is not on the PATH and not in current dir. 
                # Otherwise as above.
$ . script      # execute a script in the current dir. Will be executed in the
                # current shell environment.
$ source script # equivalent to the above *1
$ sh script     # executes 'script' in a new shell *2 (the same goes for 'bash ...',
                # 'zsh ...' etc.). Execute permission not neccessary.

Sobre a she-bangs :

Os scripts com um she-bang (por exemplo, #!/bin/sh ) na primeira linha informam qual interpretador usar.

  • Este interpretador será usado quando executado por ./script ou usando um comando: script ( script deve estar no PATH)
  • O uso de sh script ignorará o uso e o uso, neste caso, sh como o interpretador
  • O uso de . script ou source ignorará o she-bang e usará o interpretador atual (já que . ou source é equivalente a apenas executar cada linha do script no shell atual)

Notas de rodapé

* 1: Isso é quase quase verdade. No bash eles são de fato o mesmo comando, mas quando usando source , script será procurado em $ PATH antes do diretório atual. Isso é bash, mas em shells somente POSIX, source não funciona, mas . faz. Então use o último para portabilidade.

* 2: o que realmente acontece é que executamos o binário sh com 'script' como argumento, o que fará com que 'sh' execute 'script' em seu novo shell

    
por Carl 26.07.2012 / 23:52

Tags