[unix/linux] 2>&1

[Verwijderd]

2>&1 is erg handig in scripts etc.
Maar wat betekent het nu eigenlijk? Ik kom in de unix boeken niet verder dan > en < maar niet wat al die getallen eromheen nu betekenen. Weet iemand dat?

[JaQ]

Ik ken het eigenlijk alleen van scripts die je draaid in crontab. Het heeft te maken met exitcodes / feedback. Als je voor elk cronjobje dat je draait feedback wilt hebben, dan kan je het met rust laten, verschijnt het vanzelf in /var/log/messages, of in je mail, als je mail=root@localhost of iets dergerlijks plaats in je crontab file (moet je natuurlijk wel een locale mailserver hebben) als je ">/dev/null 2>&1" achter een script zet dan wordt je output weggefl#kerd.

[Sjonny]

dat zijn je filedescriptors
0 stdin
1 stdout
2 stderr
2>&1 stuurt alles van stderr naar stdout. (niet 2>1 gebruiken, want dan gaat stderr naar ./1 , een bestand dus).
>/dev/null 2>&1 stuurt alles van stdout naar /dev/null en stderr naar stdout (dus ook naar /dev/null)

[Wilke]

Dit heeft dus niks te maken met exitcodes DrFrankenstoner (wel met feedback, da's waar ).

Het is eigenlijk heel simpel inderdaad, zoals Sjonny beschrijft.

< leidt invoer van stdin om (je kunt dus een proces 'invoer van' een ander proces laten krijgen)
> stuurt stdout ergens anders heen
2> stuurt stderr ergens anders heen
>> append stdout aan een bestaande file

Als je 2>&1 gebruikt gaat inderdaad de uitvoer van 'stderr' (daar verschijnen normaal de foutmeldingen) naar 'stdout'.

Tot slot heb je dan nog '|', dat knoopt de stdin van het proces achter de '|' aan de stdout van het proces voor de '|' (m.a.w. wat het eerste proces uitspuugt gaat het tweede proces in om verder bewerkt te worden)

Zo simpel is het, als je dit weet en goed snapt, weet je de belangrijkste vorm van interprocescommunicatie in Unix.

[JaQ]

Wilke... is stderr en stdout geen exitcode? Zou wel logisch zijn anders. (exitcode=0, of true als het script correct is afgerond). Maar goed, laten we niet gaan debateren over de naam van een beesje . Bovendien ben ik ook geen xpert, ik werk pas een maand of 7 met linux.

[Verwijderd]

DrFrankenstoner schreef op 26 augustus 2002 @ 12:09:
is stderr en stdout geen exitcode?

Niet echt nee. . .

[JaQ]

Verwijderd schreef op 26 augustus 2002 @ 12:53:
[...]

Niet echt nee. . .

je hoeft niet hatelijk te gaan doen...

maar wat is het dan? (teach me... (of is dat te sarcastisch)

[JF_]

Stderr en stdout zijn file-descriptors, die normaal gesproken naar je terminal wijzen.
Stdout krijgt alle standaard output, stderr krijgt de foutmeldingen.

[blaataaps]

Wilke schreef op 26 augustus 2002 @ 12:02:


Als je 2>&1 gebruikt gaat inderdaad de uitvoer van 'stderr' (daar verschijnen normaal de foutmeldingen) naar 'stdout'.

Niet helemaal. De uitvoer van stderr gaat naar daar waar stdout op dat moment heenwijst, niet naar stdout zelf. Als je hierna stdout nogmaals redirect, heeft dat geen invloed op stderr.
Vandaar dat bijvoorbeeld bladiebla 2>&1 > /dev/null niet alle output suppressed, omdat stderr nog gewoon naar je terminal gaat.

[igmar]

JF_ schreef op 26 augustus 2002 @ 13:00:
Stderr en stdout zijn file-descriptors, die normaal gesproken naar je terminal wijzen.
Stdout krijgt alle standaard output, stderr krijgt de foutmeldingen.

Het grote verschil tussen stderr en stdout is dat stderr unbuffered is, en stdout buffered. Zaken die je naar stderr stuurt krijg je dus direct te zien, zaken naar stdout pas na een \n over het algemeen genomen.

[Verwijderd]

blaataaps schreef op 26 augustus 2002 @ 13:01:
[...]

Niet helemaal. De uitvoer van stderr gaat naar daar waar stdout op dat moment heenwijst, niet naar stdout zelf. Als je hierna stdout nogmaals redirect, heeft dat geen invloed op stderr.
Vandaar dat bijvoorbeeld bladiebla 2>&1 > /dev/null niet alle output suppressed, omdat stderr nog gewoon naar je terminal gaat.

Ja, maar ik doe dus zo:
[process] >/logfile.log 2>&1
Ik ken deze combinatie al jaren, maar heb eigenlijk nooit de gedachte erachter gekend. In dit geval gooit-ie dus alle output naar logfile.log die ik daarna kan greppen op warning en rror (ipv Error omdat error soms wel/niet met hoofdletter E wordt ge-output).

[blaataaps]

DrFrankenstoner schreef op 26 augustus 2002 @ 12:56:
[...]


je hoeft niet hatelijk te gaan doen...

maar wat is het dan? (teach me... (of is dat te sarcastisch)

stderr en stdout (en stdin) hebben te maken met waar programma's hun output heengooien (en input vandaanhalen). De exitcode staat daar idd volkomen los van. Een programma 'roept' zegmaar een getal als hij exit, als dat 0 is, betekent dat over het algemeen 'alles ging goed', alles dat geen 0 is, kan aangeven dat er iets fout is gegaan.
Zie het volgende kleine voorbeeld:

code:

$ ls /
bin   etc     home      
$ echo $?
0
$ ls /glfjdgfjdg
ls: /glfjdgfjdg: No such file or directory
$ echo $?
1
$

De variabele $? bevat de exitcode van het laatste programma, als alles lukt, is die 0, als het niet lukt, het bestand bestaat niet, is die 1. Bij elk programma kan dat verschillen, en je kunt bij verschillende fouten verschillende codes geven.

[Buffy]

Uit dit draadje:

Verwijderd schreef op 25 juli 2002 @ 22:00:
wat ook wel leuk is is dat je het kunt verkorten naar:

echo "troep" &> troep.log

[mvdejong]

Nog even een subtiel verschil in volgorde :

code:

commando >log 2>&1

: stdout en stderr naar log

code:

commando 2>&1 >log

: stdout naar log, stderr naar stdout (en dus beschikbaar voor een pipe).

code:

echo "troep" &> troep.log

Dit doet trouwens heel wat anders :
het runt het commando

code:

echo "troep"

in de achtergrond (dat is wat de "&" doet), en de output van het runnen (niet van het commando), en dat is dus altijd leeg, wordt in "troep.log" weggemoffeld.

[Verwijderd]

mvdejong schreef op 26 augustus 2002 @ 13:16:
Nog even een subtiel verschil in volgorde :

commando >log 2>&1 : stdout en stderr naar log
commando 2>&1 >log : stdout naar log, stderr naar stdout (en dus beschikbaar voor een pipe).

Dus
commando 2>&1 >log > err.log
gooit de errors in een aparte log?

[blaataaps]

Verwijderd schreef op 26 augustus 2002 @ 13:18:
[...]


Dus
commando 2>&1 >log > err.log
gooit de errors in een aparte log?

Nee, dit gooit de errors gewoon naar je terminal, en stdout in err.log.
Zie ook mijn eerste post in deze thread, 2>&1 laat stderr niet naar stdout gaan, maar naar de fd waar stdout op dat moment toevallig heenwijst.

code:

commando 2> err.log > gewoon.log

Bedoel jij denk ik.

[mvdejong]

Verwijderd schreef op 26 augustus 2002 @ 13:18:
[...]


Dus
commando 2>&1 >log > err.log
gooit de errors in een aparte log?

Nee, dat gaat fout, je zou dit kunnen oplossen als :

code:

( commando 2>&1 > log ) > err.log

maar dat kan eleganter als :

code:

commando > log 2>err.log

Waar je die truc wel voor zou kunnen gebruiken is :

code:

commando 2>&1 > log | grep -v "oninteressante foutmelding"

om de stdout in je log te stoppen, en bij het in de gaten houden van het programma niet door triviale foutmeldingen te worden gestoord.

[Buffy]

mvdejong schreef op 26 augustus 2002 @ 13:16:
[...]

code:

echo "troep" &> troep.log

Dit doet trouwens heel wat anders :
het runt het commando

code:

echo "troep"

in de achtergrond (dat is wat de "&" doet), en de output van het runnen (niet van het commando), en dat is dus altijd leeg, wordt in "troep.log" weggemoffeld.

Net nog even geprobeerd met bash:

code:

$ echo "troep" &>troep.log
$ cat troep.log
troep
$ cat foo &>troep.log
$ cat troep.log
cat: foo: No such file or directory

[mvdejong]

Ik had het hier met de Korn-shell onder AIX (IBM) en MP-RAS (NCR) geprobeerd, en daar kreeg ik het door mij beschreven effect.

[Buffy]

Hmm, geen standaard feature en dus gevaarlijk om in je scripts te gebruiken.

Goed dat ik dat weet

[Verwijderd]

Verwijderd schreef op 26 augustus 2002 @ 13:06:
[...]

Ja, maar ik doe dus zo:
[process] >/logfile.log 2>&1
Ik ken deze combinatie al jaren, maar heb eigenlijk nooit de gedachte erachter gekend. In dit geval gooit-ie dus alle output naar logfile.log die ik daarna kan greppen op warning en rror (ipv Error omdat error soms wel/niet met hoofdletter E wordt ge-output).

Een klein tipje van mijn kant

Volgende keer gewoon case insensitive greppen

grep -i dus. Dan kan je gewoon op error zoeken en pakt hij Error ook

Of zelfs voor mijn part
egrep [eE]rror (= grep -e [eE]rror)

[xzenor]

blaataaps schreef op 26 augustus 2002 @ 13:01:
[...]

Niet helemaal. De uitvoer van stderr gaat naar daar waar stdout op dat moment heenwijst, niet naar stdout zelf. Als je hierna stdout nogmaals redirect, heeft dat geen invloed op stderr.
Vandaar dat bijvoorbeeld bladiebla 2>&1 > /dev/null niet alle output suppressed, omdat stderr nog gewoon naar je terminal gaat.

Heej dat wist ik nog niet..
das een scherp punt...
Ik dacht eerst echt dat het stderr gewoon naar stdout stuurde..
dus dat >/dev/null er voor of er achter geen **** uitmaakte..

Dit kan veel frustraties gaan schelen denk ik nu ik dit weet

[Buffy]

offtopic:
Is dit misschien niet iets voor de NOS Faq aangezien je met de search niks vindt als je "2>&1" als zoekterm opgeeft?

[Verwijderd]

Dan wel kompleet in de faq, dus ook de andere 7 discriptors (3 t/m9).
Tot nu toe zijn constructies als deze:

ls -l >&3

of

exec 3>&0

nog niet in dit draadje besproken (ging het hier ook niet over), maar dit kan errug makkelijk zijn.
Lijkt me dan ook iets voor de FAQ (indien deze opgesteld gaat worden).

[Verwijderd]

Dawns_sister schreef op 26 augustus 2002 @ 18:28:

offtopic:
Is dit misschien niet iets voor de NOS Faq aangezien je met de search niks vindt als je "2>&1" als zoekterm opgeeft?

Is dit een F.A.Q. dan

Deze vraag heb ik in al die tijd dat ik hier kom, geloof ik maar 2 keer voorbij zien komen (inclusief deze topic).

[Buffy]

Ikke geloof ik drie keer (incl deze) maar kan het niet nagaan omdat de search niks oplevert.
Maar ik geef toe dat drie keer niet gelijk een F.A.Q. is. En zoals druuna aangeeft moet je dan ook gelijk alles gaan beschrijven betreffende filedescriptors wat de overzichtelijkheid van de faq niet ten goede komt.

Dacht dat het alleen handig was omdat je er niet op kan zoeken

[Verwijderd]

Als dit zo weinig gevraagd word is een verwijzing naar de dichtstbijzijnde search engine misschien een beter idee. Er is genoeg te vinden als je bv google voed met 2>&1

[blaataaps]

En het staat ook netjes in man bash, de eerste hit op zoeken naar '&1' geeft al de gewenste info, ook over het vaak vergeten feit dat de volgorde wel van belang is:

code:

           Note that the order of redirections is  significant.   For
       example, the command

              ls > dirlist 2>&1

       directs  both  standard  output  and standard error to the
       file dirlist, while the command

              ls 2>&1 > dirlist

[Wilke]

DrFrankenstoner schreef op 26 augustus 2002 @ 12:09:
Wilke... is stderr en stdout geen exitcode? Zou wel logisch zijn anders. (exitcode=0, of true als het script correct is afgerond). Maar goed, laten we niet gaan debateren over de naam van een beesje . Bovendien ben ik ook geen xpert, ik werk pas een maand of 7 met linux.

Nau ja, voor de record dan: nee stderr en stdout zijn dus echt geen exitcodes. De exitcode is dat wat een programma teruggeeft (0=success meestal, >0 = probleem/foutcode).

stderr en stdout zijn I/O-streams, da's toch echt wel iets anders en meer dan een naamgevingsverschil (zoals anderen al uitleggen).

Maar dat geeft niet, weer wat geleerd dan he

[Red Sonja]

Andere 7 descriptors
redsonja@linux:~> ls -l >&3
bash: 3: Bad file descriptor

Ok, nou wil ik ook wel weten wat die andere zijn 0,1,2 kende ik al maar, heb nooit wat gehoord van die andere... enlighten me

[ Voor 0% gewijzigd door Red Sonja op 27-08-2002 09:37 . Reden: typo ]

[Verwijderd]

Ok, kan een lang, al dan niet begrijpbaar, verhaal hier neerzetten. dat doe ik dus niet.......

Ze worden over her algemeen gebruikt bij (advanced) shell (bash/ksh/csh) programmeren. Onderstaande 2 links geven een idee wat je ermee kunt doen:

http://www.redmondlinux.c.../HTML/io-redirection.html (uitleg discriptors)

Of misschien heb je 'm wel op je eigen bak staan:

/usr/share/doc/howto/en/html/Adv-Bash-Scr-HOWTO/ (Suse heeft 'm hier staan).

Mini voorbeeld:

http://www.theauthor.net/...sh_exec_stdout_stderr.htm

Ik hoop dat je er wat aan hebt.

PS: man bash en man ksh geven ook enige info over dit onderwerp.