On Sun, Apr 14, 2002 at 05:03:38PM -0700, Wolfgang Pfeiffer wrote:
> Hi Michael,
> Thanks a lot for your help.
> Two constructs:
> " > /dev/null 2>&1"
> "2>&1 > /dev/null"
> I'm not sure whether I understood you:
> " > /dev/null 2>&1":
> #2 in this construct will be written to the same place that &1 is
> written to: /dev/null
> "2>&1 > /dev/null":
> the result of the construct seems to be the same for me as in the
> first case (both #2 and &1 being deleted), but in this case, after
> the command has written its output to #2, the latter (#2) will be
> written to &1 *and* thus will be deleting &1 before it (i.e. #2)
> will be sent to /dev/null ...
> I understand now: the result of both constructs is the *same*, but
> you seem to be disagreeing: "That ["2>&1 > /dev/null"] probably
> won't do what you want and certainly does NOT do what's above
> [i.e." > /dev/null 2>&1", and I didn't understand the rest of your
> sentence - important? - :] (unless stdout was aleady directed
> to /dev/null)."
Ok... Let me do this through example...
Script one calls script two as follows...
Script 1:
=======
#!/bin/sh -
:
exec script2 > foo1.out 2> foo1.err
=======
The above says run script2 directing stdout to foo1.out and stderr
to foo1.err.
=======
script 2:
cmd1
cmd2 > foo2.out 2>&1
cmd3 2>&1 > foo3.out
=======
In this case, the first script runs script number 2 with stdout
redirected to foo1.log and stderr to foo2.log. So, where does the
output of stdout and stderr from each of the three commands in script 2 go?
command stdout stderr
cmd1 foo1.out foo1.err
cmd2 foo2.out foo2.out
cmd3 foo3.out foo1.out
Now, the first and second commands are probably what people would
expect. It's the third one that has surprises. Why did it do what it
did. Take it in sequence. When the command interpreter processes the
command, it has stdout=foo1.out and stderr=foo1.err from the parent
shell. For this command (cmd3), it processes the 2>&1 first which tells it
to map stderr to stdout which now makes stderr=foo1.out (which, in programmer
terms, is just and fdopen of the stdout fd from the parent shell). Now,
after doing that, it is told to redirect stdout to foo3.out (this is just
a new open on the stdout fd and has no impact on the stderr fd). Note that
the redirection does NOT affect the earlier redirection which placed stderr
on foo1.out, that remains on the open file descriptor that was created for
it by the previous action. The second redirection only redirected stdout
and had no effect on stderr. Each of the redirections must be consider
in sequence from left to right autonomous from each other.
In the case that foo1.out and foo3.out are both the same (say
"/dev/null") then it is the same. But if foo1.out and foo3.out are not
the same, the result is different depending on the order of the parameters.
> Again: thanks, and my apologies for taking much of your time.
No problem. My pleasure.
> And please note that the command I'm running in my crontab is
> already doing what I want ... to understand now what it actually
> does is perhaps pure luxury ... )
No... It's not a luxury. Understanding should be fundamental.
It limits future mistakes and gives you the ability to teach others. :-)
Understanding also limits the number of unexpected and unwanted
surprises. :-) Many may know what works, it's easy to copy examples
from scripts and make it happen... Most should know WHY it works, then
you don't NEED to copy from other scripts when you are doing something
slightly different... Some also need to know how it works, programmers
sometimes get creative... Knowing "what works" will not tell you where
it doesn't work if you don't know "WHY it works".
> Regards
> Wolfgang
Regards,
Mike
--
Michael H. Warfield | (770) 985-6132 | [EMAIL PROTECTED]
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
