Comportamento ligeiramente diferente do Linux Se dermos '&' antes do redirecionamento io '>' e após o redirecionamento

Eu estava iniciando o jboss recentemente em segundo plano no Linux e vi que se você executar o comando da seguinte maneira:

nohup ./startjboss.sh > server.log &

A saída é:

[1] 18835
[root@cnt5-01b downloads]#

O terminal para o próximo comando aparece diretamente.

No entanto, se eu executar o comando da seguinte maneira:

nohup ./startjboss.sh & > server.log

Então a saída é:

[1] 19223
[root@cnt5-01b downloads]# nohup: appending output to `nohup.out'

Então, quando eu pressiono enter, ele retorna para:

[root@cnt5-01b downloads]#

qual é o terminal onde eu posso escrever o próximo comando.

Por que existe uma diferença de comportamento (é necessário um Enter extra)? Isso é uma coisa muito pequena, nem mesmo um problema; mas eu só quero saber.

Ao colocar o &, você está dizendo ao shell para executar o que o precede em segundo plano e continuar com um novo comando.

Quando você o coloca no final da linha, não há comando após, portanto o shell retorna ao modo interativo.

Quando você o coloca no meio, o shell interpreta o restante da linha como um novo comando. Esse comando redireciona a saída padrão de nothing para server.log. Como você não está redirecionando a saída do nohup, agora a vê no terminal. Como o shell já havia redesenhado seu PS1 antes, você vê essa linha de saída como se fosse um comando, mas é simplesmente uma saída de um trabalho em segundo plano. Você pode digitar seu novo comando sem pressionar Enter antes (embora não esteja claro quando você o ler mais tarde).

Bem, basicamente, quando você executa um comando &após, está perdendo algumas funcionalidades.

Tome isso como exemplo, faça um script que não faça nada além de retornar 2 por exemplo.

• execute o script normalmente, emita echo $?e você verá a saída 2.
• execute o script &depois dele, execute echo $?e você verá a saída 0.

Além disso, ao executar nohup ./startjboss.sh & > server.log, se você verificar o server.logarquivo, verá que ele está vazio, porque a saída do processo em segundo plano será 0encerrada com êxito, mas como você não echoo inseriu server.log, nada será realmente gravado server.log.