Hjemmeside » hvordan » Hvordan kører du en kommando i baggrunden uden output, medmindre der er en fejl?

    Hvordan kører du en kommando i baggrunden uden output, medmindre der er en fejl?

    Hvis du er en travl person, så er det sidste du har brug for at blive generet af en masse "ubrugelige" anmeldelser, så hvordan holder du tingene ned? Dagens SuperUser Q & A-indlæg har nogle gode svar, der hjælper en læser til at stoppe mængden af ​​output.

    Dagens Spørgsmål & Svar session kommer til os med venlig hilsen af ​​SuperUser-en underafdeling af Stack Exchange, en community-driven gruppe af Q & A-websteder.

    Spørgsmålet

    SuperUser-læser Xster ønsker at vide, hvordan man kører en kommando i baggrunden uden output, medmindre der er en fejl:

    Hvordan undertrykker du en kommandos output, men viser det, hvis kommandos exitkode koder en fejl?

    Hvordan får du en kommando til at køre i baggrunden uden output, medmindre der er en fejl?

    Svaret

    SuperUser bidragsydere Bob og Maximillian Laumeister har svaret for os. Først op, Bob:

    Desværre antages det, at stderr bruges kun til fejludgang er ikke altid korrekt. Hellere, stderr bruges ofte til alle interaktive output og diagnostik (dvs. output beregnet til brugeren at læse i en interaktiv prompte).(1) wget og dd er velkendte eksempler.

    Nogle kommandoer vil give et flag (dvs.. -rolige eller -stille) for at undertrykke ikke-fejl output. Læs deres mandsider for at se om der findes en.

    En anden konvention, der holder oftere, er exit kode, et program returnerer en exitkode, når den udgår. typisk(2), en exit kode af 0 indikerer succes, og enhver anden exitkode angiver en fejl.

    Med bash, Du kan få exit kode fra den sidste kommando fra $? variabel. I fisk, brug $ status variabel. Du kan røre stderr til en midlertidig fil og kun udskrive den, hvis der opstår en fejl. For eksempel (fisk):

    Du kan også bruge nogle genveje, hvis du ikke kæder kommandoer:

    Eller:

    Du kan også røre stdout til den samme buffer ved brug af 2> & 1> / tmp / outputbuffer.

    (Bemærk: Jeg ved faktisk ikke fisk, så jeg tilpasser konceptet til det, jeg kan finde i dokumentationen. Syntaxen kan være lidt forkert. Du kan også bruge mktemp at generere en unik midlertidig fil. Kør det og optag filnavnet i en variabel.)

    Hvis du har brug for at køre det hele i baggrunden af ​​en shell, som du også bruger interaktivt på samme tid, så er du bedre til at skrive et script til at håndtere output-gemmer og kører det script i baggrunden med standardteknikkerne (fisk). Heck, du kan sætte noget som følgende funktion i ~ / .Config / fisk / config.fish:

    Ring med run-silent somecommand & (hvor den efterfølgende & får det til at køre i baggrunden)

    Bemærk at dette vil sluge den oprindelige exitkode, og vil dumpe begge dele stdout og stderr i tilfælde af en fejl. Du kan tilpasse det efter behov.

    (1) Der er ingen garanti for, at fejl output ikke vises på stdout, nogle programmer vil dump alle output der!

    (2) Desværre er det stadig ikke altid tilfældet. Afslutningskoden styres fuldstændigt af programmet, og nogle vil indikere nogle succesbetingelser med ikke-nul-udgange. Igen skal du kontrollere manualen.

    Efterfulgt af svaret fra Maximillian Laumeister:

    Unix-værktøjer sender generelle beskeder til stdout, og fejlmeddelelser til stderr, så hvis vi kun vil se fejlmeddelelser, så vil det være tilstrækkeligt at undertrykke stdout så det kun stderr får output til konsollen.

    Måden at gøre dette på (i begge bash og fisk) er at tilføje > / Dev / null til kommandoen. Dette rør stdout i intet, men stderr (med dine fejlmeddelelser) kommer stadig igennem til konsollen.

    Så for eksempel:

    Kommandoen ekko 1> / dev / null udskriver intet, fordi det normale stdout output er undertrykt, og der er ikke skrevet noget til stderr.

    Kommandoen mand doesnotexist> / dev / null udskriver en fejlmeddelelse, fordi mand skriver sin fejlmeddelelse til stderr.


    Har du noget at tilføje til forklaringen? Lyde af i kommentarerne. Vil du læse flere svar fra andre tech-savvy Stack Exchange brugere? Tjek den fulde diskussionstråd her.