Jak uruchomić polecenie w tle bez wyjścia, chyba że wystąpił błąd?

Jeśli jesteś zajęty, to ostatnią rzeczą, której potrzebujesz, jest przeszkadzanie ogromnej ilości "bezużytecznych" powiadomień, więc jak możesz je uspokoić? Dzisiejszy post z pytaniami i odpowiedziami dla SuperUser zawiera kilka świetnych odpowiedzi, które pomogą czytelnikowi wyciszyć wydajność.

Dzisiejsza sesja pytań i odpowiedzi przychodzi do nas dzięki uprzejmości SuperUser - poddziału Stack Exchange, opartego na społecznościach grupowania witryn z pytaniami i odpowiedziami.

Pytanie

Czytnik SuperUser Xster chce wiedzieć, jak uruchomić polecenie w tle bez wyjścia, chyba że wystąpił błąd:

W jaki sposób tłumić dane wyjściowe polecenia, ale pokazać je, jeśli polecenie exit koduje błąd?

Jak uzyskać polecenie uruchamiania w tle bez wyjścia, chyba że wystąpił błąd?

Odpowiedź

Współautorzy SuperUser Bob i Maximillian Laumeister mają dla nas odpowiedź. Najpierw Bob:

Niestety, założenie, że stderr jest używany tylko do wyjścia błędu nie zawsze jest poprawne. Raczej, stderr jest często używany do wszelkich interaktywnych wyników i diagnostyki (tj. danych wyjściowych przeznaczonych dla użytkownika do czytania w interaktywnym monicie).(1) wget i dd są dobrze znanymi przykładami.

Niektóre polecenia zapewniają flagę (tj. -cichy lub -cichy), aby wyłączyć wyjście błędów. Przeczytaj ich strony man, aby sprawdzić, czy istnieje.

Inną konwencją, która ma częściej, jest kod wyjścia, program zwraca kod wyjścia po jego zakończeniu. Zazwyczaj(2), kod zakończenia 0 wskazuje na sukces, a każdy inny kod wyjścia wskazuje błąd.

Z grzmotnąć, możesz uzyskać kod zakończenia ostatniego polecenia z $? zmienna. W ryba, Użyj $ status zmienna. Możesz potokować stderr do pliku tymczasowego i drukować go tylko w przypadku wystąpienia błędu. Na przykład (ryba):

Możesz także użyć niektórych skrótów, jeśli nie łańcuchujesz poleceń:

Lub:

Możesz także potokować stdout do tego samego bufora za pomocą 2> & 1> / tmp / outputbuffer.

(Uwaga: Właściwie to nie wiem ryba, więc dostosowuję koncepcję do tego, co mogę znaleźć w jej dokumentacji. Składnia może być nieznacznie błędna. Możesz również użyć mktemp wygenerować unikalny plik tymczasowy. Uruchom go i zapisz nazwę pliku w zmiennej.)

Jeśli chcesz uruchomić całość w tle powłoki, której używasz jednocześnie w tym samym czasie, lepiej jest napisać skrypt do obsługi wyjścia - ukrywanie i uruchamianie tego skryptu w tle przy użyciu standardowych technik (ryba). Heck, możesz dodać coś takiego jak poniższa funkcja ~ / .config / fish / config.fish:

Zadzwoń z run-silent somecommand & (gdzie kończy się & powoduje, że działa w tle)

Zauważ, że połknie oryginalny kod zakończenia i zrzuci oba stdout i stderr w przypadku awarii. Możesz go dostosować w razie potrzeby.

(1) Nie ma gwarancji, że wyjście błędu nie pojawi się stdout, niektóre programy zrzucają tam wszystkie dane wyjściowe!

(2) Niestety, nie zawsze tak jest. Kod wyjścia jest całkowicie kontrolowany przez program, a niektóre będą wskazywać pewne warunki powodzenia z niezerowymi wyjściami. Ponownie sprawdź instrukcję.

Następnie odpowiedź od Maximilliana Laumeistera:

Programy uniksowe wysyłają ogólne komunikaty do stdout, i komunikaty o błędach do stderr, więc jeśli chcemy tylko zobaczyć komunikaty o błędach, wystarczy tłumić stdout więc tylko stderr pobiera dane wyjściowe do konsoli.

Sposób na zrobienie tego (w obu grzmotnąć i ryba) jest dołączenie > / dev / null do polecenia. To rury stdout w nicość, ale stderr (z twoimi komunikatami o błędach) nadal przechodzi do konsoli.

Na przykład:

Komenda echo 1> / dev / null nic nie drukuje, ponieważ normalne stdout dane wyjściowe są pomijane i nic nie zostało zapisane stderr.

Komenda man doesnotexist> / dev / null wyświetla komunikat o błędzie, ponieważ mężczyzna wypisze komunikat o błędzie do stderr.

Czy masz coś do dodania do wyjaśnienia? Dźwięk w komentarzach. Chcesz przeczytać więcej odpowiedzi od innych użytkowników Stack Exchange, którzy znają się na technologii? Sprawdź cały wątek dyskusji tutaj.