nohup sleep 10 2>/dev/null &
O comando nohup imprime uma mensagem para stderr e 2>/dev/null envia stderr para /dev/null .
Atualmente, estou usando nohup command & para enviá-lo em segundo plano. Mas o problema é:
se eu executar nohup command & eu saio como:
root@ubuntu:/home/test# nohup sleep 10 &
[2] 52439
root@ubuntu:/home/test# nohup: ignoring input and appending output to 'nohup.out'
<I need to press ENTER key here to take back my shell control.>
root@ubuntu:/home/test#
O que preciso fazer:
root@ubuntu:/home/test# nohup sleep 10 &
[2] 52439
root@ubuntu:/home/test# nohup: ignoring input and appending output to 'nohup.out'
root@ubuntu:/home/test#
Eu não quero pressionar "ENTER KEY" depois de nohup sleep 10 & .
Como, estou trabalhando na parte de automação, preciso que depois que um comando for enviado para segundo plano, eu possa executar o próximo comando sem pressionar nenhuma tecla. Como:
root@ubuntu:/home/test# nohup start-server.py &
root@ubuntu:/home/test# nohup start-client.py &
[ start-server.py precisa estar sendo executado em segundo plano.]
mas o problema é que, após start-server.py ser executado, ele não executará o próximo comando. Preciso pressionar "ENTER KEY" para ir para o próximo comando.
Existe alguma solução? Qualquer ajuda seria muito apreciada.
Não há necessidade de entrar. Basta digitar seu próximo comando e ele funcionará (o que você vê é apenas uma saída após a saída do prompt do shell). Isso é exatamente o mesmo que acontece quando você digita entrar no prompt do shell: você recebe outro prompt. : -)
Você não precisa pressionar Enter. Embora pareça que o erro padrão do nohup está na sua linha de comando, você pode "digitar", e somente o que você digita é inserido como o próximo comando.
De link
nohup só grava em nohup.out se a saída for de outro modo para o terminal. Se você redirecionar a saída do comando para outro lugar - incluindo /dev/null - é para onde ele vai.
nohup command >/dev/null 2>&1 # doesn't create nohup.out
Se você estiver usando nohup , isso provavelmente significa que você deseja executar o comando em segundo plano colocando outro & no final de tudo:
nohup command >/dev/null 2>&1 & # runs in background, still doesn't create nohup.out
No Linux, executar um trabalho com nohup fecha automaticamente sua entrada também. Em outros sistemas, notavelmente BSD e OS X, esse não é o caso, portanto, ao executar em segundo plano, você pode querer fechar sua entrada manualmente. Enquanto a entrada de fechamento não tem efeito sobre a criação ou não de nohup.out , evita outro problema: se um processo em segundo plano tentar ler qualquer coisa da entrada padrão, ele irá pausar, esperando que você traga de volta para o primeiro plano e digite algo . Então a versão extra-segura é assim:
nohup command </dev/null >/dev/null 2>&1 & # completely detached from terminal
Note, no entanto, que isso não impede que o comando acesse o terminal diretamente, nem o remova do grupo de processos do seu shell. Se você quiser fazer o último, você pode fazê-lo executando disown sem argumento como o próximo comando, ponto no qual o processo não está mais associado a um "trabalho" de shell e não terá nenhum sinais (não apenas HUP ) encaminhados para ele a partir do shell.
Explicação:
Em sistemas Unixy, cada fonte de entrada ou destino de saída tem um número associado a ele chamado de "descritor de arquivo" ou "fd" para abreviar. Todo programa em execução ("processo") tem seu próprio conjunto, e quando um novo processo é iniciado, ele tem três deles já abertos: "entrada padrão", que é fd 0, está aberta para o processo ler, enquanto "saída padrão" (fd 1) e "erro padrão" (fd 2) estão abertos para serem gravados. Se você acabou de executar um comando em uma janela de terminal, então, por padrão, qualquer coisa que você digitar vai para sua entrada padrão, enquanto a saída padrão e o erro padrão são enviados para essa janela.
Mas você pode pedir ao shell para alterar onde qualquer um ou todos esses descritores de arquivo apontam antes de iniciar o comando; é o que os operadores de redirecionamento ( < , << , > , >> ) e pipe ( | ) fazem.
O canal é o mais simples desses ... command1 | command2 faz com que a saída padrão de command1 seja alimentada diretamente na entrada padrão de command2 . Este é um arranjo muito útil que levou a um padrão de design específico em ferramentas UNIX (e explica a existência de erro padrão, que permite que um programa envie mensagens para o usuário, mesmo que sua saída vá para o próximo programa no pipeline) . Mas você só pode canalizar a saída padrão para a entrada padrão; você não pode enviar nenhum outro descritor de arquivo para um pipe sem fazer malabarismos.
Os operadores de redirecionamento são mais amigáveis, pois permitem que você especifique qual descritor de arquivo será redirecionado. Portanto, 0<infile lê a entrada padrão do arquivo denominado infile , enquanto 2>>logfile anexa erro padrão ao final do arquivo denominado logfile . Se você não especificar um número, insira o padrão de redirecionamento como fd 0 ( < é o mesmo que 0< ), enquanto o padrão de redirecionamento de saída é fd 1 ( > é o mesmo que 1> ). / p>
Além disso, você pode combinar descritores de arquivos juntos: 2>&1 significa "enviar erro padrão para onde quer que a saída padrão esteja indo". Isso significa que você obtém um único fluxo de saída que inclui o padrão padrão e o erro padrão misturados, sem nenhuma maneira de separá-los, mas também significa que você pode incluir erro padrão em um canal.
Portanto, a seqüência >/dev/null 2>&1 significa "enviar a saída padrão para /dev/null " (que é um dispositivo especial que simplesmente joga fora o que você escreve) "e enviar um erro padrão para onde a saída padrão for" (que nós apenas nos certificamos de que era /dev/null ). Basicamente, "jogue fora tudo o que este comando escreve no descritor de arquivo".
Quando nohup detecta que nem o erro nem a saída padrão está anexado a um terminal, não se preocupa em criar nohup.out , mas supõe que a saída já seja redirecionada para onde o usuário quer que ela vá.
O dispositivo /dev/null funciona para entrada também; Se você executar um comando com </dev/null , qualquer tentativa desse comando para ler a partir da entrada padrão encontrará instantaneamente o fim do arquivo. Observe que a sintaxe de mesclagem não terá o mesmo efeito aqui; ele só funciona para apontar um descritor de arquivo para outro que esteja aberto na mesma direção (entrada ou saída). O shell permitirá que você faça >/dev/null <&1 , mas acabará criando um processo com um descritor de arquivo de entrada aberto em um fluxo de saída, portanto, em vez de apenas atingir o final do arquivo, qualquer tentativa de leitura disparará um descritor de arquivo inválido "fatal" "erro.