tail не блокирует
Как всегда: для всего есть ответ, который короток, прост для понимания, легок для понимания и совершенно неверен. Здесь tail -f /dev/null попадает в эту категорию;)
Если вы посмотрите на него с strace tail -f /dev/null, вы заметите, что это решение далеко не блокирует! Вероятно, это даже хуже, чем решение sleep в этом вопросе, поскольку оно использует (под Linux) драгоценные ресурсы, такие как система inotify. Также другие процессы, которые пишут в /dev/null, делают цикл tail. (На моем Ubuntu64 16.10 это добавляет несколько 10 системных вызовов в секунду в уже занятой системе.)
Вопрос был к команде блокировки
К сожалению, такой вещи нет ..
Читайте: я не знаю, как архивировать это напрямую с помощью оболочки.
Все (даже sleep infinity) может быть прервано каким-либо сигналом. Поэтому, если вы хотите быть действительно уверенным, что он не исключительно возвращается, он должен работать в цикле, как вы уже сделали для вашего sleep. Обратите внимание, что (в Linux) /bin/sleep ограничено 24 днями (взгляните на strace sleep infinity), поэтому лучшее, что вы можете сделать, это:
while :; do sleep 2073600; done
(Обратите внимание, что я считаю, что sleep зацикливается внутри для более высоких значений, чем 24 дня, но это означает: это не блокирование, а очень медленное зацикливание. Так почему бы не переместить этот цикл наружу?)
.. но вы можете подойти совсем неназванным fifo
Вы можете создать что-то, что действительно блокирует, пока нет никаких сигналов, посылаемых процессу. Следующее использование bash 4, 2 PID и 1 fifo:
bash -c 'coproc { exec >&-; read; }; eval exec "${COPROC[0]}<&-"; wait'
Вы можете проверить, что это действительно блокирует с помощью strace, если хотите:
strace -ff bash -c '..see above..'
Как это было построено
read блокируется, если нет входных данных (см. Некоторые другие ответы). Однако tty (он же stdin) обычно не является хорошим источником, так как он закрывается, когда пользователь выходит из системы. Также это может украсть некоторые данные из tty. Не красиво.
Чтобы сделать блок read, нам нужно ждать что-то вроде fifo, которое никогда ничего не вернет. В bash 4 есть команда, которая может точно предоставить нам такой fifo: coproc. Если мы также подождем блокировки read (что является нашим coproc), мы закончили. К сожалению, для этого нужно держать открытыми два PID и fifo.
Вариант с именем fifo
Если вы не удосужились использовать именованное fifo, вы можете сделать это следующим образом:
mkfifo "$HOME/.pause.fifo" 2>/dev/null; read <"$HOME/.pause.fifo"
Не использовать цикл при чтении немного небрежно, но вы можете использовать это fifo столько раз, сколько захотите, и завершить read s, используя touch "$HOME/.pause.fifo" (если есть более одного ожидания чтения , все прекращаются сразу).
Или используйте системный вызов Linux pause()
Для бесконечной блокировки существует вызов ядра Linux, называемый pause(), который делает то, что мы хотим: ждать вечно (пока не поступит сигнал). Однако для этого пока нет программы для пользователя.
C
Создать такую программу легко. Вот фрагмент кода для создания очень маленькой программы для Linux под названием pause, которая приостанавливается на неопределенный срок (требуется diet, gcc и т. Д.):
printf '#include <unistd.h>\nint main(){for(;;)pause();}' > pause.c;
diet -Os cc pause.c -o pause;
strip -s pause;
ls -al pause
python
Если вы не хотите что-то компилировать самостоятельно, но у вас установлено python, вы можете использовать это под Linux:
python -c 'while 1: import ctypes; ctypes.CDLL(None).pause()'
(Примечание: используйте exec python -c ... для замены текущей оболочки, это освобождает один PID. Решение может быть улучшено также путем некоторого перенаправления ввода-вывода, освобождая неиспользуемые FD.
Как это работает (я думаю): ctypes.CDLL(None) загружает стандартную библиотеку C и запускает в ней функцию pause() в некотором дополнительном цикле. Менее эффективен, чем версия C, но работает.
Моя рекомендация для вас:
Оставайтесь в зацикленном сне. Это легко понять, очень переносимо и большую часть времени блокирует.