Cronjob

[Pierre Bernhardt]

> 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 

>/dev/null 2>&1

das gleiche Ergebnis bringen.

Komischerweise seh ich da gar nix: Bsp.:

# (echo hallo; cat blasuelz)
hallo
cat: cannot open blasuelz

# (echo hallo; cat blasuelz) >/dev/null 2>&1

Wenn ich aber die Umleitungen austausche:

# (echo hallo; cat blasuelz) 2>&1 >/dev/null
cat: cannot open blasuelz

Folgendes nun umgekehrt ausprobiert:
# (echo hallo; cat blasuelz) 2>/dev/null >&2 

# (echo hallo; cat blasuelz) >&2 2>/dev/null
hallo

Ich versteh da noch net so richtig die logic dahinter. Wird das von hinten
nach
vorne ausgewertet?

Also  mal probiert:

# (echo hallo; cat blasuelz) >&2 2>/dev/null &>/testfile
# cat testfile
hallo
cat: cannot open blasuelz

Aha. Sieh wohl danach aus. Naja, so richtig scchlau werd ich aus der logic
nicht,
denn dann muesste ja die pipe | genau solch einer Reglementierung
unterworfen sein.

Dachte ich jedenfalls immer. Also doch mal nen Buch ueber shells kaufen...

Nachdenklich hinterlassener...
Pierre



Wieder einen bug auf meiner Festplatte behoben.

-- 
--
Pierre Bernhardt