Hello. :)
I have this script:
script name: t
*******************
#!/bin/bash
echo "Hello!"
rm godsend
*******************
However, the following two different commands have two different
output results, Why ?
It makes me confusing. It seems to have the same meaning, but result
differs in its output, Why?
Please help !!
$ ./t 2>&1 > er
$ ./t > er 2>&1
On 2007-10-10, jaeh wrote:
>
> I have this script:
>
> script name: t
> *******************
> #!/bin/bash
> echo "Hello!"
> rm godsend
> *******************
>
> However, the following two different commands have two different
> output results, Why ?
> It makes me confusing. It seems to have the same meaning, but result
> differs in its output, Why?
> Please help !!
>
> $ ./t 2>&1 > er
>
> $ ./t > er 2>&1
The redirection goes to wherever its target is at the time of
redirection. The command line is evaluated left to right, so in the
first example, stderr is redirected to wherever stdout (&1) is
currently pointing. Changing stdout later (> er) does not affect
the earlier redirection of stderr.
It's like a variable being assigned by value rather than by
reference.
A=1
B=$A
A=2
Changing A after B has been assigned doesn't affect B.
--
Chris F.A. Johnson, author
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
===== My code in this post, if any, assumes the POSIX locale
===== and is released under the GNU General Public Licence
On Tue, 09 Oct 2007 18:34:24 -0700, jaeh wrote:
> Hello. :)
> I have this script:
>
> script name: t
> *******************
> #!/bin/bash
> echo "Hello!"
> rm godsend
> *******************
>
> However, the following two different commands have two different output
> results, Why ?
> It makes me confusing. It seems to have the same meaning, but result
> differs in its output, Why?
> Please help !!
>
> $ ./t 2>&1 > er
>
> $ ./t > er 2>&1
It would probably be sensible to have you script generate something you
can recognise to both stdout and stderr, e.g.
#!/bin/bash
printf "This went to fd1\n"
printf "This went to fd2\n" >&2
and then you can see better the effect. In the first case you should see
"This went to fd2" on your terminal, as *at the time it did the 2>&1, 1
was connected to your terminal*, and "This went to fd1" should be in the
file er.
In the second case you should see both messages in er, because when fd2
was redirected to fd1, then fd1 was connected to the file.
jaeh
> However, the following two different commands have two different
> output results, Why ?
>
> $ ./t 2>&1 > er
>
> $ ./t > er 2>&1
>
Perhaps check this tutorial:
http://bash-hackers.org/wiki/doku.php?id=howto:redirection_t utorial
--
pgas@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
In article <470c6f5d$0$79898$742ec2ed@news.sonic.net>,
Icarus Sparry
....
>It would probably be sensible to have you script generate something you
>can recognise to both stdout and stderr, e.g.
The implication was that there is no such file as "godsend", so the "rm"
is generating an err msg on stderr.
On Wed, 10 Oct 2007 10:12:28 +0000, Kenny McCormack wrote:
> In article <470c6f5d$0$79898$742ec2ed@news.sonic.net>, Icarus Sparry
>
>>It would probably be sensible to have you script generate something you
>>can recognise to both stdout and stderr, e.g.
>
> The implication was that there is no such file as "godsend", so the "rm"
> is generating an err msg on stderr.
Yes, I recognised this. However if there was such a file before the two
runs of the program it would also explain the difference in the output!
I stick with my suggestion that creating clearly labled output is
"probably sensible", and this is even more true once you start using file
descriptors numbered more than 2, e.g. if you try and follow the logic of
the code in "csh considered harmful" for getting the return code of the
first process in a pipe (and don't have something like bash's PIPESTATUS
array).
On Oct 9, 6:34 pm, jaeh
> It makes me confusing. It seems to have the same meaning, but result
> differs in its output, Why?
> Please help !!
>
> $ ./t 2>&1 > er
>
> $ ./t > er 2>&1
Shell redirections manipulate the file descriptor space of the process
(via the open and dup2 system calls). They are processed left to
right.
Thus
2>&1 >file
means:
dup2(1, 2); /* make fd 2 the same as 1 */
dup2(open("file", ...), 1); /* open file as fd 1 */
As you can see, in this case, fd's 1 and 2 end up with different
objects. What was originally on 1 is now on 2, and 1 is replaced with
a file.
If you reverse the redirections:
>file 2>&1
then the operations are likewise reversed:
dup2(open("file", ...), 1); /* install file as fd 1 */
dup2(1, 2); /* copy 1 to 2 */
So the effect now is that both 1 and 2 go to the file.