Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site well.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!ucbvax!ucdavis!lll-crg!well!fnf
From: fnf@well.UUCP (Fred Fish)
Newsgroups: net.unix-wizards
Subject: Re: Redirection quirks: 2>&1 >file  -- vs. --  >file 2>&1
Message-ID: <424@well.UUCP>
Date: Sat, 4-Jan-86 18:02:09 EST
Article-I.D.: well.424
Posted: Sat Jan  4 18:02:09 1986
Date-Received: Mon, 6-Jan-86 03:21:25 EST
References: <649@watmath.UUCP>
Reply-To: fnf@well.UUCP (Fred Fish)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 23

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
===============================================================================