最後に「command＆」を使用するか、「nohup command＆」を使用してコマンドをデタッチしたいのですが、デタッチするとすぐに停止します。
コマンドはほとんど具体的ではありません。入力でeofを受け取ると、コマンドが壊れるので、入力が終了し、通常は機能する解決策につながるため、/ dev / null：
$ command < /dev/null > /dev/null 2>&1 &
動作していません…
unix / linuxに、/ dev / nullを置き換えて空の入力のように動作できるが、eofを送信しない他のデバイスはありますか。
（ちなみに、コマンドは非常に便利なマルチキャストツールemcastです。自分でパッチを適用するか、この目的のためにパッチを適用したバージョンを見つけることができます…しかし、問題は外部で解決できるようです）
質問をより明確にするために、この編集を追加します。私はこの2行のCプログラムを作成しました。これは、完全に機能します。プログラム名は「donothing」です
#include <unistd.h>
int main() { while (1) { sleep(10); } return 0; }
そしてそれは私が探しているものであり、何もしないデバイス/プログラムですが、そのstdoutは開いたままにしておきます。 （「command＆…disown」と「nohupcommand＆」）の両方が機能します。
$ donothing | mycommand >/dev/null &
$ disown %1
うまく機能するので、今の質問は、unixデバイス/プログラムが私の「ドノシング」のように動作するかどうかだけです。
承認された回答：
eofを検出するコマンドの場合 、stdinから読み取る必要があります。したがって、おそらくそれは何らかの入力を期待しています。したがって、必要なのは空の入力ではないようです（/dev/null まさにそのためのものです）が、決して来ない入力です。
これは、次のように誰も反対側に書き込むことのないパイプでシミュレートできます。
sleep 999999999 | the-command
または、余分なsleepを実行する必要をなくすため コマンド、それは名前付きパイプで行うことができます：
fifo=$(mktemp -u) &&
mkfifo "$fifo" &&
(rm "$fifo" && the-command <&3 3<&- &) 3<> "$fifo"
ここでは、中間ファイル記述子を使用して、シェルがstdinを/dev/nullに接続するという事実を回避します。 &でコマンドを開始すると暗黙的に （<&3のような明示的なstdinリダイレクトを追加しない限り ここに）。
Linux（およびおそらくLinuxのみ）では、次のこともできます。
the-command < /dev/fd/1 3>&1 > /dev/null | :
/dev/fd/1 Linuxでは、fd 1がパイプに接続されている場合、名前付きパイプのように動作します。つまり、読み取りモードで開くと、パイプの読み取り端が表示されます。
したがって、上記では、fd 0は、もう一方の端がthe-commandのfd3にあるパイプの読み取り端に接続されます。 。 the-command fd3には何も書き込みません。read fd 0を試行すると、ブロックされます（または、ブロックされていない読み取りは、まだ読み取るものがないで返されます。 、またはselect/pollは何も読みませんを返します the-commandとして 来ることのない入力を待つ以外のことをしているのなら、おそらくやっているでしょう。