por que executar um comando shell do Linux com &?

Question

Estou usando o Red Hat Enterprise Linux versão 5. Tenho notado que as pessoas às vezes executam comandos com algumas opções & . Por exemplo, no comando abaixo, há dois sinais & . Qual é o propósito deles? Eles são sempre usados juntos com nohup?

nohup foo.sh <script parameters> >& <log_file_name> &

    

Answer 1

Além das respostas de Martin, Ash e Kevin, às vezes você verá um e comercialmente usado matematicamente para um bit a bit AND ^* :

$ echo $(( 11 & 7 ))
3

Caso você não esteja familiarizado com operadores de bits:

11: 1011
 7: 0111
-------- AND
 3: 0011

Em cada posição há um bit no primeiro número E no segundo número, defina esse bit para um na resposta.

^{* _{O recurso na resposta de Kevin é chamado de lógico AND.}}

Para elaborar a resposta de Ash, quando usado no redirecionamento, o "e" comercial pode dizer ao shell para copiar um descritor de arquivo. Neste comando echo "hello" > outputfile 2>&1 o E comercializa qualquer saída que pode ir para erro padrão (stderr, descritor de arquivo 2) para ir para o mesmo lugar como saída padrão (stdout, descritor de arquivo 1, o padrão para o lado esquerdo de > ). O operador >& outputfile é uma abreviação para > outputfile 2>&1 .

Além disso, novo no Bash 4, há dois novos terminadores para cláusulas no comando case ;& e ;;& que afetam se um caso "cai" e, em caso afirmativo, se o próximo teste é executado .

    

Answer 2

No script de shell bash, o "&" é usado para separar processos:

find -name hello &

Faz com que o comando "Localizar" seja bifurcado e executado em segundo plano (você sempre pode eliminá-lo por meio do PID).

    

Answer 3

why run a Linux shell command with &?

Para recuperar seu prompt imediatamente e execute o processo em segundo plano.

What are the function of them?

nohup permite que o processo em segundo plano continue sendo executado mesmo depois que o usuário efetuar logout (ou sair do shell inicial).

> & redireciona a saída padrão e o erro padrão para o arquivo de log.

& executa a coisa toda em segundo plano, retornando imediatamente ao seu pedido.

Explicação:

Todo processo Linux abre três canais de E / S, uma entrada "stdin", uma saída padrão "stdout" e uma saída de erro padrão "stderr". Eles podem ser usados para binário, mas são tradicionalmente texto. Quando a maioria dos programas vêem stdin close, eles saem (isso pode ser mudado pelo programador).

Quando o shell pai sai, stdin é fechado nos filhos e (geralmente, geralmente) os filhos também saem. Além disso, as crianças recebem um sinal de software, SIGHUP, indicando que o usuário "desligou" (anteriormente, o modem) e o padrão aqui é sair também. (Note que um programador pode mudar tudo isso ao escrever o programa).

Assim, o que nohup faz é dar ao filho um ambiente separado de E / S, amarrando os meandros a algo que não esteja ligado ao shell pai e protegendo o filho do sinal SIGHUP. Depois que o usuário se desconectar, você verá o processo de segundo plano nohup de propriedade do init (processo 1), não do shell do usuário.

No entanto, o nohup não pode realizar o trabalho completamente se o processo for executado em primeiro plano, portanto & é usado para executar o programa em segundo plano, onde ele pode ficar feliz correndo com ou sem um usuário logado.

    

Answer 4

Além da resposta do @ Martin: O outro uso do "e" comercial ( >& como acima) é capturar stdout e stderr . Normalmente, se você redirecionasse a saída para um arquivo com apenas '>', você só obteria a saída para stdout , sem erros.

    

Answer 5

Além da resposta de Martin e Ash, às vezes você pode ver o uso de um token && . Isso é usado para dizer "execute o segundo comando se e somente se o primeiro comando foi executado com êxito". Um comando bem escrito irá, se tiver algum erro, não sair com sucesso.

[kevin@box ~]$ ls file && echo removing file && rm file
ls: file: No such file or directory
[kevin@box ~]$ touch file
[kevin@box ~]$ ls file && echo removing file && rm file
file
removing file
[kevin@box ~]$

    

Answer 6

A resposta de Martin é boa, mas um pouco ambígua. O comando é sempre fork'ed e exec'ed, mas o comportamento normal do shell é aguardar o comando até que ele saia. O e comercial coloca em segundo plano para que você obtenha o seu terminal de volta e você pode fazer outras coisas. Se o processo enviar dados para stdout ou stderr, isso será misturado com o que você estiver fazendo no prompt e poderá confundi-lo. É por isso que você redireciona depois com > & /path/to/logfile.txt.

Em resposta a George2, o comportamento normal de uma saída de shell é enviar o sinal SIGHUP para todos os processos no mesmo grupo de processos (essencialmente o que você gerou) e eles geralmente terminarão. Se você quiser que isso continue, mesmo se você fechar o processo shell, você pode usar o comando nohup para fazê-los ignorar este sinal e continuar correndo. Há um nome especial para esse tipo de processo, chamado de processo daemon (pronunciado 'demon').