19Aug

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

click fraud protection

Om du är en upptagen person, är det sista du behöver för att vara störd med en stor mängd "värdelösa" meddelanden, 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 fråga &Svarssession 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 output om inte ett fel uppstår?

Svaret

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

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

instagram viewer

Vissa kommandon kommer att ge en flagga( dvs -quiet eller -silent ) 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 -utgångskoden , ett program returnerar en exit-kod när den går ut. Typiskt ( 2) indikerar en exitkod för 0 framgång, och någon annan exitkod indikerar ett fel.

Med bash kan du få utkodskoden för det sista kommandot från $? variabel. I fisk , använd $ status variabeln. Du kan pipa stderr till en temporär fil och skriva ut det endast om ett fel inträffar. 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 & gt; 1 & gt;/tmp/ utgångbuffert .

( Anm.: Jag vet faktiskt inte 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ärfil. Kör den och registrera filnamnet i en variabel.)

Om du behöver köra hela saken i bakgrunden till ett skal som du också använder interaktivt samtidigt, så är du bättre att skriva ett manus för att hanterautmatningen döljer och kör det skriptet i bakgrunden med standardteknikerna( fisk ).Heck, du kan lägga något som följande funktion i ~ /.config/fish/ config.fish :

Samtal med kör-tyst somecommand &( där den efterföljande & orsakar att den körs i bakgrunden)

Observera att detta kommer att svälja den ursprungliga exitkoden och kommer att dumpa både stdout och stderr vid ett fel. Du kan anpassa den efter behov.

( 1) Det finns ingen garanti för att felutgången inte kommer att visas på stdout , vissa program dumpar all utdata 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å attendast stderr får utgång till konsolen.

Sättet att göra detta( i både bash och fisk ) är att lägga till & gt;/dev/ null till kommandot. Det här röret stiger till ingenting, men stderr ( med dina felmeddelanden) kommer fortfarande till konsolen.

Så till exempel:

Kommandot echo 1 & gt;/dev/ null skriver ingenting, eftersom den vanliga stdout -utmatningen undertrycks, och inget skrivs till stderr .

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

Har 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.