Hur kör du ett kommando i bakgrunden utan någon utmatning, såvida det inte finns ett fel?

Om du är en upptagen person, så är det sista du behöver vara störd med en stor mängd "värdelösa" anmälningar, så hur slår du saker ner? Dagens SuperUser Q & A-inlägg har några bra svar för att hjälpa en läsare att sänka antalet utdata.

Dagens Question & Answer-session kommer till oss med tillstånd av SuperUser-en indelning av Stack Exchange, en community-driven gruppering av Q & A-webbplatser.

Frågan

SuperUser-läsare Xster vill veta hur man kör ett kommando i bakgrunden utan utdata om inte ett fel finns:

Hur undertrycker du ett kommandos utdata, men visar det om kommandot avslutar koder ett fel?

Hur får du ett kommando att köra i bakgrunden utan utdata om inte ett fel uppstår?

Svaret

SuperUser-bidragsgivare Bob och Maximillian Laumeister har svaret för oss. Först upp, Bob:

Tyvärr antagandet att stderr används endast för felutgång är inte alltid korrekt. Snarare, stderr används ofta för alla interaktiva utdata och diagnostik (dvs. utdata som är avsedd för användaren att läsa i en interaktiv prompten).(1) wget och dd är välkända exempel.

Vissa kommandon kommer att ge en flagga (dvs.. -tyst eller -tyst) för att undertrycka icke-felutgång. Läs deras man sidor för att se om det finns en.

En annan konvention som rymmer oftare är avgångskod, ett program returnerar en exit-kod när den går ut. Typiskt(2), en exitkod av 0 indikerar framgång, och någon annan avgångskod indikerar ett fel.

Med våldsamt slag, Du kan få avkodskoden från det sista kommandot från $? variabel. I fisk, Använd $ status variabel. Du kan pipa stderr till en tillfällig fil och skriv ut det endast om ett fel uppstår. Till exempel (fisk):

Du kan också använda några genvägar om du inte kedjar kommandon:

Eller:

Du kan också pipa stdout till samma buffert genom att använda 2> & 1> / tmp / utgångbuffert.

(Notera: Jag vet inte faktiskt fisk, så jag anpassar konceptet till vad jag kan hitta i dokumentationen. Syntaxen kan vara lite fel. Du kan också använda mktemp för att skapa en unik temporär fil. Kör det och registrera filnamnet i en variabel.)

Om du behöver köra hela saken i bakgrunden av ett skal som du också använder interaktivt samtidigt, är det bättre att du skriver ett manus för att hantera utmatningen och dölja det manuset i bakgrunden med standardteknikerna (fisk). Heck, du kan lägga något som följande funktion i ~ / .Config / fisk / config.fish:

Ring med kör-tyst somecommand & (där den efterföljande & får det att springa i bakgrunden)

Observera att detta kommer att svälja den ursprungliga exitkoden, och kommer att dumpa båda stdout och stderr i händelse av ett misslyckande. Du kan anpassa det efter behov.

(1) Det finns ingen garanti för att felutgången inte kommer att visas på stdout, vissa program dumpar all produktion där!

(2) Tyvärr är detta fortfarande inte alltid fallet. Utgångskoden styrs helt av programmet och vissa kommer att indikera några framgångsbetingelser med utgångar utan noll. Återigen, kolla in handboken.

Följd av svaret från Maximillian Laumeister:

Unix-verktyg skickar allmänna meddelanden till stdout, och felmeddelanden till stderr, så om vi bara vill se felmeddelanden är det tillräckligt att undertrycka stdout så det bara stderr får utmatning till konsolen.

Sättet att göra detta (i båda våldsamt slag och fisk) är att lägga till > / Dev / null till kommandot. Detta rör stdout in i ingenting, men stderr (med dina felmeddelanden) kommer fortfarande till konsolen.

Så till exempel:

Kommandot eko 1> / dev / null skriver ingenting, för det normala stdout utmatningen är undertryckt och inget skrivs till stderr.

Kommandot man does nototexist> / dev / null skriver ett felmeddelande, eftersom man skriver sitt felmeddelande till stderr.

Har du något att lägga till förklaringen? Ljud av i kommentarerna. Vill du läsa mer svar från andra tech-savvy Stack Exchange-användare? Kolla in hela diskussionsgängan här.