Terminal fredag: Standard Stream

Välkommen till ytterligare en fredag ​​...

Det är dags att lära känna en liten del av terminalen. Efter mycket eftertanke bestämde jag mig för att skapa ett inlägg om standardströmmar; Även om det kommer att vara ytligt, tror jag att det är något som alla borde veta.

Standardström

Standardström Den består av flera kommunikationskanaler mellan användaren och terminalen. Dessa in- / utgångskanaler visar eller samlar in information när ett kommando utförs.

Snabbdiagram över standardströmmar.

De 3 I / O-anslutningarna är: stdin Standardinmatning, stdout Standardutgång, stderr Standard fel.

stdin: Standardingång

Standardinmatning är det sätt på vilket vi fångar information från ett kommando, antingen genom rör, omdirigering, tangentbord etc. Vi identifierar det med filbeskrivaren 0.

Ett exempel på stdin skulle vara:

sortera <listning

Det tar all information som finns i listan - i det här fallet siffrorna skrivna slumpmässigt - och när du omdirigerar filen till kommandot ls sorterar den den numeriska listan alfabetiskt. I detta exempel är flaggorna implicita.

stdout: Standardutgång

Standardutdata, som namnet antyder, visar utdata från ett kommando via konsolen. Om vi ​​skriver ls är all information som visas på skärmen standardutdata. Det representeras av deskriptor 1.

Nu ska jag försöka starta stdin och stdout med ett manus skrivet i bash, helt enkelt för att jag älskar bash hahaha. 🙂

test.sh

#! / bin / bash om [-t 0]; sedan echo "Du använder stdout" elif [-t 1]; sedan echo "Du använder stdin" annars echo "Brutal error" fi

Nu en skärmdump som visar hur man använder manuset. När du omdirigerar eller använder ett rör med skriptanvändningen testa -t att veta om bara stdout-skriptet körs, och om inte är det uppenbarligen stdin.

bash test.sh ls | bash test.sh bash test.sh </ etc / passwd

Skriptet i fråga och dess utdata ...

Kom ihåg att ändra kommandot och öva så att du lär dig.

stderr: Standardfel

Standardfel är hur program visar fel eller diagnostik. Det representeras av deskriptor 2.

För att förstå konceptet är detta situationen: när vi vill spara ett fel från ett kommando är det första vi tänker på att omdirigera utdata till vanlig text.

ls> info.txt

Detta skulle fungera, kommandouppgifterna sparas i en vanlig textfil. Men när du sparar felet lagras det inte, men det visas på skärmen och klartextfilen är tom.

Istället om vi använder 2> för att ange att spara stderr i filen:

ls foo 2> info.txt

Nu kommer det att spara felinformationen i textfilen.

De flesta Shell tillåt att stderr och stdout lagras i ett enda kommandokommando med &> där Foo är en katalog som inte finns

ls Nedladdningar Foo &> info.txt

Den här filen kommer att innehålla informationen om felet när du kör ls i Foo och listar katalogerna under Nedladdningar.

Och slutligen, vad gör det berömt 2> & 1?

Enkel, omdirigera stderr till stdout. Det & mitt i> och 1 betyder att det kommer att omdirigeras till stdout. Om den inte var där skulle det vara ungefär som ... "omdirigera felet till fil 1".

Och med detta är det möjligt att omdirigera:

• stdout till en fil
• stderr till en fil
• stdout till stderr
• stderr till stdout
• stderr och stdout till en fil
• bland annat

Det är det för dagens människor. Vi läser och tackar dig för att du kom förbi. 😀