gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/03/86)
> $ command 2>&1 >file > $ command >file 2>&1 > > These are not equivalent using our 4.2bsd Bourne shell. They're not supposed to be. The redirections are performed in the order given.
ken@turtlevax.UUCP (Ken Turkowski) (01/03/86)
In article <649@watmath.UUCP> idallen@watmath.UUCP writes: > $ command 2>&1 >file > $ command >file 2>&1 >These are not equivalent using our 4.2bsd Bourne shell. (The 2>&1 in the >first line redirects unit 2 to the tty, not to the file.) >Is this a feature or a bug? Comments not worthy of world-wide >net readership should be mailed to me, not posted, please. Yes, this is how it works. Redirections are parsed and executed in order, so that in the first case, fd2 is dup'ed from fd1, and then fd1 is redirected, and in the second case fd1 is redirected, followed by fd2 being dup'ed from the new fd1. -- Ken Turkowski @ CIMLINC, Menlo Park, CA UUCP: {amd,decwrl,hplabs,seismo,spar}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.DEC.COM
fnf@well.UUCP (Fred Fish) (01/05/86)
In article <649@watmath.UUCP> idallen@watmath.UUCP writes: >Consider: > > $ command 2>&1 >file > $ command >file 2>&1 > >These are not equivalent using our 4.2bsd Bourne shell. (The 2>&1 in the >first line redirects unit 2 to the tty, not to the file.) As I'm sure many others will point out, the action is entirely reasonable. Arguments are processed as found, so in the first command, 2>&1 says to send 2's stuff to wherever 1 is going. Since both are probably already going to the tty, it is effectively a no-operation. The later >file then sends 1's stuff off to "file". In the second command, by the time 2>&1 is processed, 1 is already going to "file", so 2 goes there too. -Fred -- =============================================================================== Fred Fish (415) 644-1230 ext 242 ucbvax!unisoft!fnf well!fnf ===============================================================================
rs@mhuxd.UUCP (Robert Sanderman) (01/05/86)
> > $ command 2>&1 >file > > $ command >file 2>&1 I understand why the above are different but why do the following two lines produce different results: $ 2>&1 command > file $ command 2>&1 > file Bob Sanderman ihnp4!mhuxd!rs
jsdy@hadron.UUCP (Joseph S. D. Yao) (01/05/86)
In article <3957@mhuxd.UUCP> rs@mhuxd.UUCP (Robert Sanderman) writes: >> > $ command 2>&1 >file >> > $ command >file 2>&1 >I understand why the above are different but why do the following >two lines produce different results: > $ 2>&1 command > file > $ command 2>&1 > file Interesting! Trying permutations, you get: 2,1 diverted 1 only diverted $ command >file 2>&1 $ command 2>&1 >file $ 2>&1 command > file $ 2>&1 > file command $ >file 2>&1 command $ >file command 2>&1 Looks like it takes the '>' tokens from the front and appends them. Not having source in hand, I'd not venture to say. -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
carl@bdaemon.UUCP (carl) (01/06/86)
> In article <649@watmath.UUCP> idallen@watmath.UUCP writes: > >Consider: > > > > $ command 2>&1 >file > > $ command >file 2>&1 > > > >These are not equivalent using our 4.2bsd Bourne shell. (The 2>&1 in the > >first line redirects unit 2 to the tty, not to the file.) > The real explanation for all of this is that once a Bourne shell command line has been read (up to \n or ; or & etc.) it is evaluated from right to left. To convince yourself, try foobar=${foo}${bar} foo="hello" bar=" world" versus foo="hello" bar=" world" foobar=${foo}${bar} Carl Brandauer {allegra|amd|attunix|cbosgd|ucbvax|ut-sally}!nbires!bdaemon!carl
doug@ides.UUCP (Douglas J. Wait) (01/06/86)
> Consider: > > $ command 2>&1 >file > $ command >file 2>&1 > > These are not equivalent using our 4.2bsd Bourne shell. (The 2>&1 in the > first line redirects unit 2 to the tty, not to the file.) > Is this a feature or a bug? Comments not worthy of world-wide > net readership should be mailed to me, not posted, please. > -- > -IAN! (Ian! D. Allen) University of Waterloo Have you read your documentation ? .... Mine tells me that: "... The shell evaluates redirections left-to-right. For example: ... 1>xxx 2>&1 first associates file descriptor 1 with file xxx. It associates file descriptor 2 with the file associated with file descriptor 1 (i.e., xxx). If the order of redirections were reversed, file descriptor 2 would be assocated with the terminal .... This is from SysVr2 sh(1). -- Doug Wait AT&T Information Systems 850 Trafalgar Ct. Maitland, FL 32751 (305)660-3471 ..!{akgua,ihnp4,abcom}!ides!doug "Is anyBODY OUT there..."
jsdy@hadron.UUCP (Joseph S. D. Yao) (01/06/86)
In article <350@bdaemon.UUCP> carl@bdaemon.UUCP (carl) writes: >> In article <649@watmath.UUCP> idallen@watmath.UUCP writes: >> > $ command 2>&1 >file >> > $ command >file 2>&1 >> >These are not equivalent using our 4.2bsd Bourne shell. (The 2>&1 in the >> >first line redirects unit 2 to the tty, not to the file.) >The real explanation for all of this is that once a Bourne shell command >line has been read (up to \n or ; or & etc.) it is evaluated from right to >left. To convince yourself, try > foobar=${foo}${bar} foo="hello" bar=" world" >versus > foo="hello" bar=" world" foobar=${foo}${bar} Since the '>'s are obviously interpreted left to right, this can't be universally true. Apparently, some things are interpreted left-right and others right-left. Actually, I would have expected the assignments to be interpreted in parallel, and so in both they would have assigned foobar = "". -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
ken@rochester.UUCP (Ipse dixit) (01/06/86)
Alright you guys, figure this one out then:
--------------------
->> cat d.c
main()
{
printf("Hello world\n");
if (open("/etc/phones", 2) < 0)
perror("/etc/phones");
}
->> a.out 2>&1 > xxx
/etc/phones: No such file or directory
->> cat xxx
Hello world
->> a.out > xxx 2>&1
->> cat xxx
/etc/phones: No such file or directory
Hello world
->> 2>&1 a.out > xxx
->> cat xxx
/etc/phones: No such file or directory
Hello world
->>
-------------------
What I really want to know is, what *should* it do? I find sh(1) very
uninformative, with some mumble about duplicating file descriptors.
Don't get me wrong, I've used Unix for years, but I find the
explaination in sh(1) so obtuse that I just look at some old sh files
when I want to get work done.
Ken
--
UUCP: ..!{allegra,decvax,seismo}!rochester!ken ARPA: ken@rochester.arpa
Snail: Comp. of Disp. Sci., U. of Roch., NY 14627. Voice: Ken!john@basser.oz (John Mackin) (01/08/86)
In article <350@bdaemon.UUCP> carl@bdaemon.UUCP (Carl Brandauer) writes: > The real explanation for all of this is that once a Bourne shell command > line has been read (up to \n or ; or & etc.) it is evaluated from right to > left. Incorrect. In the case you gave, evaluation may indeed proceed from right to left; the order of evaulation is not documented. But if you examine the original posting, you will see the statement > $ command 2>&1 >file > $ command >file 2>&1 > The 2>&1 in the first line redirects unit 2 to the tty, not to the file. This statement is *correct*. The redirections are evaluated from LEFT to RIGHT, not from right to left. In the (Eighth Edition) sh(1) manual entry on our system, this behavior is documented: The order in which redirections are specified is significant. The shell evaluates redirections left-to- right. For example: ... 1>xxx 2>&1 first associates file descriptor 1 with file xxx. It associates file descriptor 2 with the file associated with file descriptor 1 (i.e. xxx). If the order of redirections were reversed, file descriptor 2 would be associated with the terminal (assuming file descriptor 1 had been) and file descriptor 1 would be associated with file xxx. John Mackin, Basser Department of Computer Science, University of Sydney, Sydney, Australia seismo!munnari!basser.oz!john john%basser.oz@SEISMO.CSS.GOV