Jak nic nie robić wiecznie w elegancki sposób?

Mam program, który generuje przydatne informacje, stdoutale także czyta z stdin. Chcę przekierować standardowe wyjście do pliku, nie udostępniając niczego na standardowym wejściu. Jak dotąd tak dobrze: mogę zrobić:

program > output

i nie rób nic w tty.

Problem polega jednak na tym, że chcę to zrobić w tle. Jeśli zrobię:

program > output &

program zostanie zawieszony („zawieszony (wejście tty)”).

Jeśli zrobię:

program < /dev/null > output &

program kończy się natychmiast, ponieważ osiąga EOF.

Wydaje się, że potrzebuję połączyć się z programczymś, co nie robi niczego przez czas nieokreślony i nie czyta stdin. Działa następujące podejście:

while true; do sleep 100; done | program > output &
mkfifo fifo && cat fifo | program > output &
tail -f /dev/null | program > output &

Wszystko to jest jednak bardzo brzydkie. Tam ma być elegancki sposób, przy użyciu standardowych narzędzi systemu Unix, aby „nie robić nic, na czas nieokreślony” (parafrazując man true). Jak mogłem to osiągnąć? (Moje główne kryteria elegancji tutaj: brak plików tymczasowych; brak zajętych oczekiwań lub okresowych pobudek; brak egzotycznych narzędzi; możliwie najkrótszy.)

W powłokach, które je obsługują (ksh, zsh, bash4), możesz zacząć programjako koproces .

• ksh: program > output |&
• zsh, bash:coproc program > output

Który rozpoczyna programsię w tle z jego wejście, które zostało przekształcone od A pipe. Drugi koniec rury jest otwarty dla skorupy.

Trzy zalety tego podejścia

• bez dodatkowego procesu
• możesz wyjść ze skryptu, gdy programumiera (użyj, waitaby na niego poczekać)
• programzakończy działanie (wejdzie eofna standardowe wejście, jeśli powłoka wyjdzie).

Nie sądzę, że będziesz bardziej elegancki niż

tail -f /dev/null

które już zasugerowałeś (zakładając, że używa to wewnętrznie inotify, nie powinno być sondowania ani wybudzeń, więc poza dziwnym wyglądem powinno wystarczyć).

Potrzebujesz narzędzia, które będzie działać przez czas nieokreślony, utrzyma stdout otwarte, ale tak naprawdę nie napisze niczego na stdout i nie wyjdzie, gdy jego stdin jest zamknięte. Coś takiego yesfaktycznie pisze na standardowe wyjście. catwyjdzie, gdy jego standardowe wejście zostanie zamknięte (lub zrobione zostanie cokolwiek, na co zostaniesz przekierowany). Myślę, że sleep 1000000000dmoże działać, ale tailjest wyraźnie lepiej. Moje pudełko Debiana ma tailfnieco skrócone polecenie.

Biorąc pod uwagę inny sprzęt, co powiesz na uruchomienie programu screen?

sleep infinity to najczystsze znane mi rozwiązanie.

Możesz użyć, infinityponieważ sleepakceptuje liczbę zmiennoprzecinkową * , która może być dziesiętna , szesnastkowa , nieskończoności lub NaN , zgodnie z man strtod.

* To nie jest część standardu POSIX, więc nie jest tak przenośna jak tail -f /dev/null. Jest jednak obsługiwany w jądrach GNU (Linux) i BSD (używany na Macu) (najwyraźniej nie jest obsługiwany w nowszych wersjach Maca - patrz komentarze).

sleep 2147483647 | program > output &

Tak, 2^31-1jest liczbą skończoną i nie będzie trwać wiecznie , ale dam ci 1000 $, kiedy sen wreszcie się skończy. (Wskazówka: do tego czasu jedno z nas nie żyje).

• brak plików tymczasowych; czek.
• bez czekania lub okresowych wybudzeń; czek
• bez egzotycznych narzędzi; czek.
• tak krótko, jak to możliwe. Okej, może być krótszy.

Możesz utworzyć plik binarny, który robi to samo za pomocą:

$ echo 'int main(){ pause(); }' > pause.c; make pause

Oto kolejna sugestia użycia standardowych narzędzi uniksowych, aby „nic nie robić w nieskończoność” .

sh -c 'kill -STOP $$' | program > output

Spowoduje to uruchomienie powłoki, która jest natychmiast wysyłana SIGSTOP, co powoduje zawieszenie procesu. Jest to używane jako „dane wejściowe” do programu. Uzupełnieniem SIGSTOPjest SIGCONT, tzn. Jeśli wiesz, że powłoka ma PID 12345, możesz kill -CONT 12345ją kontynuować.

W systemie Linux możesz wykonać:

read x < /dev/fd/1 | program > output

W Linuksie, otwarcie / dev / fd / x, gdzie x jest deskryptorem pliku do końca zapisu potoku, daje ci koniec odczytu potoku, więc tutaj to samo, co na standardowym programie. Zasadniczo więc readnigdy nie powróci, ponieważ jedyną rzeczą, która może napisać do tego potoku, jest sama i readniczego nie wyświetla.

Będzie również działał na FreeBSD lub Solaris, ale z innego powodu. Tam otwarcie / dev / fd / 1 daje ci taki sam zasób jak open na fd 1, tak jak można się spodziewać i jak większość systemów z wyjątkiem Linuksa, więc koniec pisania potoku. Jednak w FreeBSD i Solaris potoki są dwukierunkowe. Tak długo, jak programnie pisze do standardowego wejścia (żadna aplikacja tego nie robi), nie readbędzie nic czytać z tego kierunku potoku.

W systemach, w których potoki nie są dwukierunkowe, readprawdopodobnie wystąpi błąd przy próbie odczytu z deskryptora pliku tylko do zapisu. Należy również pamiętać, że nie wszystkie systemy mają /dev/fd/x.

Stephane Chazelas' read rozwiązanie działa na Mac OS X, a także czy fd odczyt zostanie otwarty /dev/fd/1.

# using bash on Mac OS X
# -bash: /dev/fd/1: Permission denied
read x </dev/fd/1 | cat >/dev/null
echo ${PIPESTATUS[*]}   #  1 0

exec 3<&- 3</dev/fd/1
read x 0<&3 | cat >/dev/null
echo ${PIPESTATUS[*]}   #  0 0

Aby móc zabijać tail -f /dev/nullw skrypcie (na przykład za pomocą SIGINT), konieczne jest tło tailpolecenia i wait.

#!/bin/bash
# ctrl-c will kill tail and exit script
trap 'trap - INT; kill "$!"; exit' INT
exec tail -f /dev/null & wait $!

Przekieruj /dev/zerojako standardowe wejście!

program < /dev/zero > output &