andy@xwkg.Icom.Com (Andrew H. Marrinson) (12/28/90)
In the process of porting smail3.1.19 to System V release 4, I found
a very nasty bug! If you use exec to redirect output in a while loop
(as in ``exec >/tmp/foo'', that is an exec with no command), it only
seems to obey the first such redirection. I RTFM and it gives me no
reason to believe this is other than a bug. (Note: this is Bourne
shell. I haven't checked ksh yet.)
Here is a short shell script that reproduces the behavior:
while read b; do
exec > $b
cat <<EOF
this is $b.
EOF
done
If you run this with the input
file1
file2
You get a single file, file1, containing the two lines
this is file1.
this is file2.
Rather than two separate files, file1 and file2, each containing their
respective single lines!
Weird, huh?
I got this result using Dell Unix. I suspect that it is an AT&T bug,
though. I can't imagine Dell fooled with Bourne shell at all. Let me
know if there is a release 4 System V out there that doesn't do this!
Oh yes, Unix is a registered trademark of AT&T. :-)
--
Andrew H. Marrinson
Icom Systems, Inc.
Wheeling, IL, USA
(andy@icom.icom.com)lcz@dptspd.sat.datapoint.com (Lee Ziegenhals) (12/28/90)
andy@xwkg.Icom.Com (Andrew H. Marrinson) writes: >In the process of porting smail3.1.19 to System V release 4, I found >a very nasty bug! If you use exec to redirect output in a while loop >(as in ``exec >/tmp/foo'', that is an exec with no command), it only >seems to obey the first such redirection. I RTFM and it gives me no >reason to believe this is other than a bug. (Note: this is Bourne >shell. I haven't checked ksh yet.) I ran into the same problem, doing the same thing you were. Ksh does not have the same problem, so I was able to work around it. Sure threw me for a while, though... >I got this result using Dell Unix. I suspect that it is an AT&T bug, >though. I can't imagine Dell fooled with Bourne shell at all. Let me >know if there is a release 4 System V out there that doesn't do this! It happened to me using the SVR4 code straight from AT&T, so it isn't anything Dell did.
jsadler@misty.boeing.com (Jim Sadler) (12/29/90)
I tried it on HP-UX 7.0 from HP and it workd as expected. The line "this is file1" is in a file called file1. And "this is file2" was in file2. Looks like HP was on the ball. jim sadler 206-234-9009 email uunet!bcstec!jsadler | jsadler@misty.boeing.com This service is brought to you by the computing mafia of Boeing (BCS). Oh ya None of the above is an opinion of The Boeing Co.
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/31/90)
In article <andy.662338820@xwkg> andy@xwkg.Icom.Com (Andrew H. Marrinson) writes: | If you run this with the input | | file1 | file2 | | You get a single file, file1, containing the two lines Actually, if you forget to put "exec >/dev/tty" after the loop you will get a lot more than two lines... | I got this result using Dell Unix. I suspect that it is an AT&T bug, | though. I can't imagine Dell fooled with Bourne shell at all. Let me | know if there is a release 4 System V out there that doesn't do this! Use your ksh! Seems to work there. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (12/31/90)
In article <270001@misty.boeing.com> jsadler@misty.boeing.com (Jim Sadler) writes: | | I tried it on HP-UX 7.0 from HP and it workd as expected. The line "this | is file1" is in a file called file1. And "this is file2" was in file2. What is the relationship between HP-UX 7.0 and V.4? -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
jsadler@misty.boeing.com (Jim Sadler) (01/01/91)
/ misty:comp.bugs.sys5 / davidsen@sixhub.UUCP (Wm E. Davidsen Jr) / 8:09 pm Dec 30, 1990 / In article <270001@misty.boeing.com> jsadler@misty.boeing.com (Jim Sadler) writes: >| >| I tried it on HP-UX 7.0 from HP and it workd as expected. The line "this >| is file1" is in a file called file1. And "this is file2" was in file2. > > What is the relationship between HP-UX 7.0 and V.4? None that I know of, HP-UX is a V.2-V.3 base with lots of BSD thrown in. >-- >bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) jim sadler 206-234-9009 email uunet!bcstec!jsadler | jsadler@misty.boeing.com This service is brought to you by the computing mafia of Boeing (BCS). Oh ya None of the above is an opinion of The Boeing Co.
chet@thor (Chet Ramey) (01/02/91)
>>| >>| I tried it on HP-UX 7.0 from HP and it workd as expected. The line "this >>| is file1" is in a file called file1. And "this is file2" was in file2. HP's /bin/sh is still based on the s5r2 /bin/sh. HP-UX 8.0 is rumored to have both a /bin/sh based on the s5r3 sh and ksh-88. >> What is the relationship between HP-UX 7.0 and V.4? >None that I know of, HP-UX is a V.2-V.3 base with lots of BSD thrown in. HP-UX is based on 4.2 BSD at the kernel level. Most of the user code is from V.2-V.3. Libraries, too. Chet -- Chet Ramey ``I die, Horatio'' Network Services Group, Case Western Reserve University chet@ins.CWRU.Edu My opinions are just those, and mine alone.
andyc@bucky.intel.com (Andy Crump) (01/02/91)
The bug exists in AT&T's latest version of SVR4. The problem has been
submitted to them to be fixed.
--
-- Andy Crump
...!tektronix!reed!littlei!andyc | andyc@littlei.intel.com
...!uunet!littlei!andyc | andyc@littlei.uu.net
Disclaimer: Any opinions expressed here are my own and
not representive of Intel Corportation.tneff@bfmny0.BFM.COM (Tom Neff) (01/02/91)
In article <ANDYC.91Jan2085324@bucky.intel.com> andyc@bucky.intel.com (Andy Crump) writes: >The bug exists in AT&T's latest version of SVR4. The problem has been >submitted to them to be fixed. Andy, does "AT&T's latest version" in the above quote mean Version 2.0? Or something later still, aka the "production release" we're awaiting? In other words, is this Bourne bug confined to the developer releases or will there have to be a *second* production release before it's fixed? -- For the curious: +---+ Tom Neff Here's what RS-232 pins do! ==|:::|== tneff@bfmny0.BFM.COM -- Inmac +---+ uunet!bfmny0!tneff
tim@delluk.uucp (Tim Wright) (01/02/91)
In <270001@misty.boeing.com> jsadler@misty.boeing.com (Jim Sadler) writes: >I tried it on HP-UX 7.0 from HP and it workd as expected. The line "this >is file1" is in a file called file1. And "this is file2" was in file2. >Looks like HP was on the ball. Since when was HP-UX 7.0 derived from SVR4 code ?? It ain't broken anywhere else (as far as I know), only in V.4. RTFSL :-) Tim -- Tim Wright, Dell Computer Corp. (UK) | Email address Bracknell, Berkshire, RG12 1RW | Domain: tim@dell.co.uk Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim "What's the problem? You've got an IQ of six thousand, haven't you?"
ndjc@hobbit.UUCP (Nick Crossley) (01/03/91)
This exec bug does NOT appear to be in the SPARC version of V.4, in either sh or ksh. -- <<< standard disclaimers >>> Nick Crossley, ICL NA, 9801 Muirlands, Irvine, CA 92718-2521, USA 714-458-7282 uunet!ccicpg!ndjc / ndjc@ccicpg.UUCP
peter@micromuse.co.uk (Peter Galbavy) (01/03/91)
In article <tim.662826491@holly> tim@delluk.uucp (Tim Wright) writes: >Since when was HP-UX 7.0 derived from SVR4 code ?? It ain't broken anywhere >else (as far as I know), only in V.4. RTFSL :-) > ? RTFM (M = manual) ? RTFSL (SL = ??) Cheers, -- Peter Galbavy Tech Support, Micromuse Ltd Phone: +44 71 352 7774 E-Mail: P.Galbavy@micromuse.co.uk Disclaimer: Time flies like an arrow... Fruit flies like a banana
tim@delluk.uucp (Tim Wright) (01/04/91)
In <1991Jan03.092225.29230@micromuse.co.uk> peter@micromuse.co.uk (Peter Galbavy) writes: >In article <tim.662826491@holly> tim@delluk.uucp (Tim Wright) writes: >>Since when was HP-UX 7.0 derived from SVR4 code ?? It ain't broken anywhere >>else (as far as I know), only in V.4. RTFSL :-) >> >? RTFM (M = manual) >? RTFSL (SL = ??) Subject line ! -- Tim Wright, Dell Computer Corp. (UK) | Email address Bracknell, Berkshire, RG12 1RW | Domain: tim@dell.co.uk Tel: +44-344-860456 | Uucp: ...!ukc!delluk!tim "What's the problem? You've got an IQ of six thousand, haven't you?"
andyc@bucky.intel.com (Andy Crump) (01/05/91)
>>>>> On 2 Jan 91 10:08:41 GMT, tneff@bfmny0.BFM.COM (Tom Neff) said: Tom> In article <ANDYC.91Jan2085324@bucky.intel.com> andyc@bucky.intel.com (Andy Crump) writes: >The bug exists in AT&T's latest version of SVR4. The problem has been >submitted to them to be fixed. Tom> Andy, does "AT&T's latest version" in the above quote mean Version 2.0? Tom> Or something later still, aka the "production release" we're awaiting? This "latest version" referred to is post version 2.0 and not in production yet. Tom> In other words, is this Bourne bug confined to the developer releases or Tom> will there have to be a *second* production release before it's fixed? Maybe, it depends whether it gets fixed before USL lets it go. It has been reported to them. That is all the info I have right now. -- -- Andy Crump ...!tektronix!reed!littlei!andyc | andyc@littlei.intel.com ...!uunet!littlei!andyc | andyc@littlei.uu.net Disclaimer: Any opinions expressed here are my own and not representive of Intel Corportation.
guy@auspex.auspex.com (Guy Harris) (01/05/91)
>This exec bug does NOT appear to be in the SPARC version of V.4, >in either sh or ksh. So if it was fixed by somebody working on the SPARC version, has that fix been sent back to AT&T? The theory is, after all, that V.4 is V.4 is V.4; I wouldn't want to have to choose a processor for my desktop based on which versions of some bit of processor-independent code got into the official releases for various processors. Who is the "keeper" of the various V.4 ports to the "major" microprocessors? Does USL keep them all in-house - in which case one would hope that they would have a *single* source tree for all of them, with machine-independent code *including* most of the kernel shared between all processors, or at least that they'd be working on doing so - or are some of them only in the hands of the organization that did the port and their customers?
ndjc@hobbit.UUCP (Nick Crossley) (01/10/91)
In article <5048@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >So if it was fixed by somebody working on the SPARC version, has that >fix been sent back to AT&T? Unfortunately, I don't know the answer to that (yet). ICL did send (nearly) complete V.4 SPARC source code with bug fixes back to AT&T, and then AT&T took that over to produce the SPARC reference source, making various other changes of their own. For various silly reasons, we do not yet have a copy of that reference source here in Irvine. (The "nearly" bit is because there are some proprietary additions not part of the common V.4 source, such as our multiprocessor code). If the bug was found and fixed after the reference source handover, then it is likely that it has not been sent to AT&T. The best I can do is diff the ICL and AT&T versions when we get the latter. > The theory is, after all, that V.4 is V.4 >is V.4; I wouldn't want to have to choose a processor for my desktop >based on which versions of some bit of processor-independent code got >into the official releases for various processors. > >Who is the "keeper" of the various V.4 ports to the "major" >microprocessors? Does USL keep them all in-house - in which case one >would hope that they would have a *single* source tree for all of them, >with machine-independent code *including* most of the kernel shared >between all processors, or at least that they'd be working on doing so - >or are some of them only in the hands of the organization that did the >port and their customers? This whole area does seem a little weak to me. There are some areas of the source tree which are radically different from one port to another, to the extent of offering completely different facilities. (One such area is the compilation system; for example, the current SPARC version does not support COFF, and has a radically different C code generator and optimiser from the other machines). I believe that most of the porting groups have sent their code back to AT&T, but there does appear to be some delay in the merging of these - if indeed AT&T have any intent of doing such a merge. -- <<< standard disclaimers >>> Nick Crossley, ICL NA, 9801 Muirlands, Irvine, CA 92718-2521, USA 714-458-7282 uunet!ccicpg!ndjc / ndjc@ccicpg.UUCP