* Tobias Rittweiler wrote/schrieb:
> -- fuer mich ist dass zu wirrwar. kannst dudas vielleicht nochmal grad
> erklaeren, weil ich diesem verhalten einfach keinen sinn sehen
> will..
>
> btw.
> /bin/foo >/tmp/foo.out 2>&1
> /bin/foo 2>&1 >/tmp/foo.out
>
> -> harr, jetzt erklaer mal, wie das mit der Aussage abgedeckt
> wird, dass bash dabei von links nach recht abarbeitet..
Hatten wir das Thema nicht schonmal vor ein paar Wochen auf der Liste, oder
habe ich damit im stillen K�mmerlein herumprobiert?
Vielleicht ist die Erkl�rung aus der ksh-Manpage besser als die aus bash(1):
... 2>&1
means file descriptor 2 is to be opened for writing as a
duplicate of file descriptor 1.
The order in which redirections are specified is signifi-
cant. The shell evaluates each redirection in terms of the
(file descriptor, file) association at the time of evalua-
tion. For example:
... 1>fname 2>&1
first associates file descriptor 1 with file fname. It then
associates file descriptor 2 with the file associated with
file descriptor 1 (that is fname). If the order of redirec-
tions were reversed, file descriptor 2 would be associated
with the terminal (assuming file descriptor 1 had been) and
then file descriptor 1 would be associated with file fname.
Die Kernaussage ist: Wenn Du 2 nach 1 umleitest, leitest Du in Wirklichkeit
nicht nach 1 um, sondern dahin, wo 1 in diesem Moment *hinzeigt*. Wenn Du 1
danach wieder �nderst, ist die Umleitung von 2 davon nicht mehr betroffen.
-martin
--
martin@fred:~ > dd if=/dev/urandom of=~/.signature bs=1 count=120
----------------------------------------------------------------------------
PUG - Penguin User Group Wiesbaden - http://www.pug.org