Por que executar um comando de shell do Linux com '&'?

Estou usando o Red Hat Linux Enterprise versão 5. Notei pessoas às vezes executando comandos com algumas &opções. Por exemplo, no comando abaixo, existem dois &sinais. Qual é o propósito deles? Eles sempre são usados ​​junto com nohup?

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

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

$ 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 como um na resposta.

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

Para elaborar a resposta de Ash, quando usado no redirecionamento, o e comercial pode dizer ao shell para copiar um descritor de arquivo. Nesse comando, echo "hello" > outputfile 2>&1o e comercial faz com que qualquer saída que possa ir para o erro padrão (stderr, descritor de arquivo 2) vá para o mesmo local da saída padrão (stdout, descritor de arquivo 1, o padrão para o lado esquerdo >). O >& outputfileoperador é uma abreviação de > outputfile 2>&1.

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

Em um script de shell Bash, o e comercial "&" é usado para bifurcar processos:

find -name hello &

Isso fará com que o comando find seja bifurcado e executado em segundo plano (você sempre pode matá-lo pelo seu PID).

Por que executar um comando de shell do Linux com '&'?

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

Qual é a função deles?

nohup permite que o processo em segundo plano continue em execução mesmo depois que o usuário efetua logout (ou sai 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 sua solicitação imediatamente.

Explicação:

Todo processo do 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ários, mas são tradicionalmente textos. Quando a maioria dos programas vê o stdin fechar, eles saem (isso pode ser alterado pelo programador).

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

Portanto, o que o nohup faz é fornecer ao processo filho um ambiente de E / S separado, vinculando entradas e saídas a algo que não esteja vinculado ao shell pai e protegendo o filho do sinal SIGHUP. Depois que o usuário se desconectar, você verá o processo em segundo plano nohup pertencente ao init (processo 1), não ao shell do usuário.

No entanto, nohupnão é possível executar o trabalho completamente se o processo for executado em primeiro plano, por isso &é usado para executar o programa em segundo plano, onde ele pode continuar sendo executado com ou sem um usuário conectado.

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

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 for executado com êxito". Um comando bem escrito, se houver algum erro, não será encerrado com êxito.

[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 ~]$

A resposta de Martin é boa, mas um pouco ambígua. O comando sempre é bifurcado e executado, mas o comportamento normal do shell é aguardar o comando até que ele saia. Oe comercial coloca-o em segundo plano, para que você receba de volta o prompt do terminal e faça outras coisas. Se o processo distribuir dados para stdout ou stderr, isso será misturado com o que você estiver fazendo no prompt e poderá confundi-lo. É por isso que você o redireciona com> & /path/to/logfile.txt.

Em resposta ao George2, o comportamento normal de um shell sair é enviar o sinal SIGHUP para todos os processos no mesmo grupo de processos (essencialmente coisas que você gerou) e eles geralmente serão encerrados. Se você desejar que isso continue mesmo se você fechar o processo do shell, poderá usar o comando nohup para fazer com que eles ignorem esse sinal e continuem em execução. Há um nome especial para esse tipo de processo, chamado de processo daemon (pronunciado 'demônio').