🚀 go-pugleaf

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.

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.  

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

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

/ 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.  

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

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.

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

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?"

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

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

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?"

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

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

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