voglio staccare il comando con "comando &" alla fine o con "nohup comando &", ma si interrompe subito dopo averlo staccato.
il comando è poco specifico, se riceve eof in input, si interrompe in modo /dev/null poiché l'input porterà alla fine e alla soluzione che di solito funziona:
$ command < /dev/null > /dev/null 2>&1 &
non funziona...
c'è un altro dispositivo in unix/linux, che può sostituire /dev/null e comportarsi come un input vuoto, ma non inviare eof.
(a proposito, il comando è uno strumento di multicasting molto utile emcast, posso provare a patcharlo da solo o trovare una versione patchata per questo scopo... ma sembra che il problema possa essere risolto all'esterno)
Aggiungo questo EDIT per rendere più chiara la mia domanda. Ho realizzato questo programma C di 2 righe che funziona perfettamente:il nome del programma è "donothing"
#include <unistd.h>
int main() { while (1) { sleep(10); } return 0; }
ed è quello che sto cercando, un dispositivo/programma, che non fa nulla, ma lascia il suo stdout aperto. Entrambi ("command &... disown" e "nohup command &") funzionano.
$ donothing | mycommand >/dev/null &
$ disown %1
funziona bene, quindi ora la domanda è solo:quale dispositivo/programma Unix si comporta come il mio "donothing".
Risposta accettata:
Affinché il tuo comando rilevi eof , deve leggere da stdin. Quindi presumibilmente si aspetta qualche input. Quindi sembra che ciò di cui hai bisogno non sia un input vuoto (/dev/null è esattamente pensato per questo), ma input che non arrivano mai.
Può essere simulato con una pipe dove nessuno scriverà mai all'altra estremità come:
sleep 999999999 | the-command
O per evitare di dover eseguire quel sleep extra comando, potrebbe essere eseguito con una pipe denominata:
fifo=$(mktemp -u) &&
mkfifo "$fifo" &&
(rm "$fifo" && the-command <&3 3<&- &) 3<> "$fifo"
Qui usando un descrittore di file intermedio per aggirare il fatto che la shell connette stdin a /dev/null implicitamente quando avvii un comando con & (a meno che tu non aggiunga un reindirizzamento stdin esplicito come il nostro <&3 qui).
Su Linux (e probabilmente solo su Linux), puoi anche fare:
the-command < /dev/fd/1 3>&1 > /dev/null | :
/dev/fd/1 dove fd 1 è connesso a una pipe, su Linux, si comporta come una named pipe. Cioè, quando lo apri in modalità lettura, ottieni l'estremità di lettura della pipe.
Quindi sopra, fd 0 sarà collegato all'estremità di lettura di un tubo la cui altra estremità è su fd 3 di the-command . Perché the-command non scriverà nulla sul suo fd 3, nessun read il tentativo su fd 0 si bloccherà (o verrà restituita una lettura non bloccante con non c'è ancora niente da leggere o una selezione/sondaggio restituirà niente da leggere sia come the-command probabilmente sta facendo se sta facendo qualcos'altro che aspettare un input che non arriva mai).