Cronjob

[Jan-Benedict Glaw]

On Tue, 2002-11-26 14:07:10 +0100, Pierre Bernhardt <mirrorgate at gmx.de>
wrote in message <9908.1038316030 at www14.gmx.net>:
> > On Tue, 2002-11-26 09:26:06 +0100, Ralph Meyer <ralph.meyer at kludi.de>
> > wrote in message
> > <32899.193.0.21.30.1038299166.squirrel at kww.kludi.eisenberg
> > .de>:
> > 
> > 2>&1 > /dev/null
> > 
> > Der fd von stdout wird kopiert auf das, was fd2 ist (damit werden die
> > stderr-Ausgaben dahin geschickt, wo bisher stdout landet). Anschießend
> > wird stdout geerdet. Übrig bleibt stderr, und der landet nun da, wo
> > vorher stdout gewesen wäre.
> 
> Ja, funktionieren tuts so. Das weiss ich. Aber leider wird net von vorne
> nach
> hinten ausgewertet. Wenn dem so waere , wuerde 
[...]

Es _wird_ streng von vorn nach hinten abgearbeitet, nur ist die Logik
anders, als man's sich so aus dem Stand vorstellen würde. Kannst Du ein
wenig C? Selbst wenn nicht, dieses kleine "&" vor einer Zahl (einem file
descriptor) deutet den Aufruf der libc-Funktion dup() (bzw. dup2()) an.

"2>&1" heißt also:

	"Schließe FD 2. Dann lege eine Kopie von FD 1 an und nenne diese
	Kopie FD 2".

Das fologende "> /dev/null" heißt dann:

	"Schließe FD 1 (default resp stdout), öffne /dev/null und
	nenne diesen resultierenden file descriptor FD 1".

Nun hast Du den Zustand, daß FD2 auf das zeigt, was fürher mal FD1 war
(ist also normaler Terminal-Output), und FD1 ist auf /dev/null geerdet.

Wenn Du das in umgegehrter Reihenfolge angibts ( > /dev/null 2>&1), dann
wird zuerst FD 1 geschlossen und mit /dev/null neu geöffnen. _Danach_
wird FD 2 zugemacht und mit dem, was FD 1 _momentan_ ist (/dev/null) neu
geöffnet. Damit hast Du effektiv jeglichen Output geerdet.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw at lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur
    fuer einen Freien Staat voll Freier Bürger" | im Internet!
   Shell Script APT-Proxy: http://lug-owl.de/~jbglaw/software/ap2/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20021126/8f8e28cd/attachment.sig>