🚀 go-pugleaf

In article <1991May30.034223.29061@digibd.com> rick@digibd.com (Rick Richardson) writes:
>I'm posting this here in the hopes that the various
>vendors of SVR4 fix this in their next releases.
>Known to fail on AT&T, HCI, Commodore, and i860 SVR4's.

Your program DOES NOT FAIL on AT&T UNIX System V/386 Release 4.0 Version 2.1.
I verified that it works fine with the ksh and the sh.

Sincerely,

John Ben Urban
>
>#
>#	Demonstrates bug in SVR4 /bin/sh
>#	Works OK with /bin/sh on SVR3 and XENIX
>#	Works OK with /bin/ksh on SVR4
>#
>#	Should output the first line of /etc/passwd four times
>#	Only does it three times on SVR4 and then hangs
>#
>#	Seems to be related to changing fd0 in a function
>#
>read_by_func() {
>	exec 3<&0 0<$1
>	read x
>	echo $x
>	exec 0<&3 3<&-
>}
>
>exec 3<&0 0</etc/passwd
>read x
>echo $x
>exec 0<&3 3<&-
>
>exec 3<&0 0</etc/passwd
>read x
>echo $x
>exec 0<&3 3<&-
>
>read_by_func /etc/passwd
>
># Gets stuck here with /bin/sh...
>read_by_func /etc/passwd
>-- 
>Rick Richardson		Email: rick@digibd.com
>Senior MTS		Fax: (612) 943-0803
>DigiBoard, Inc.		Tel: (612) 943-5383

  >In article <1991May30.171404.23422@cbnewsl.att.com> urban@cbnewsl.att.com (john.urban) writes:

     In article <1991May30.034223.29061@digibd.com> rick@digibd.com (Rick Richardson) writes:
     >I'm posting this here in the hopes that the various
     >vendors of SVR4 fix this in their next releases.
     >Known to fail on AT&T, HCI, Commodore, and i860 SVR4's.

  >   Your program DOES NOT FAIL on AT&T UNIX System V/386 Release 4.0 Version 2.1.
  >   I verified that it works fine with the ksh and the sh.

  >   Sincerely,

  >   John Ben Urban

The program DOES indeed fail on AT&T UNIX System V/386 Release 4.0 Version 3.0.
I verified that the Bourne shell does fail the test.

Sincerely,

John Litvin

---

Script started on Fri May 31 09:55:55 1991
$ uname -a
jade jade 4.0 3.0 i386 386/AT
$ sh /tmp/bug
root:x:0:1:0000-Admin(0000):/:
root:x:0:1:0000-Admin(0000):/:
root:x:0:1:0000-Admin(0000):/:

$ ksh /tmp/bug
root:x:0:1:0000-Admin(0000):/:
root:x:0:1:0000-Admin(0000):/:
root:x:0:1:0000-Admin(0000):/:
root:x:0:1:0000-Admin(0000):/:
$

script done on Fri May 31 09:56:08 1991

John Litvin
jlitvin@morticia.intel.com

In article <1991May30.171404.23422@cbnewsl.att.com>, urban@cbnewsl.att.com (john.urban) writes:
|> In article <1991May30.034223.29061@digibd.com> rick@digibd.com (Rick Richardson) writes:
|> >I'm posting this here in the hopes that the various
|> >vendors of SVR4 fix this in their next releases.
|> >Known to fail on AT&T, HCI, Commodore, and i860 SVR4's.
|> 
|> Your program DOES NOT FAIL on AT&T UNIX System V/386 Release 4.0 Version 2.1.
|> I verified that it works fine with the ksh and the sh.
|> 
|> Sincerely,
|> 
|> John Ben Urban

Well, that may be true, but the AT&T Release 4.0 Version 3.0 'reference port' 
or 'Test Engine' as it is sometimes called definitely DOES FAIL.  It is 
somewhat interesting that if you run it under ksh with: 'truss shbug' it will
also fail at the same point it does in sh.

-- 
Randy Howard                        !'s:uunet!dell!mustang!jrh  
Dell Computer Corp.                 @'s:jrh@mustang.dell.com

In article <20798@uudell.dell.com> jrh@mustang.dell.com (Randy Howard) writes:
>In article <1991May30.171404.23422@cbnewsl.att.com>, urban@cbnewsl.att.com (john.urban) writes:
>|> In article <1991May30.034223.29061@digibd.com> rick@digibd.com (Rick Richardson) writes:
>|> >Known to fail on AT&T, HCI, Commodore, and i860 SVR4's.
>|> Your program DOES NOT FAIL on AT&T UNIX System V/386 Release 4.0 Version 2.1.
>|> I verified that it works fine with the ksh and the sh.

It will work with ksh - see below.

>
>Well, that may be true, but the AT&T Release 4.0 Version 3.0 'reference port' 
>or 'Test Engine' as it is sometimes called definitely DOES FAIL.  It is 
>somewhat interesting that if you run it under ksh with: 'truss shbug' it will
>also fail at the same point it does in sh.

This bug is caused by the same problem that was mentioned some time ago
in this group, namely redirection on 'exec' and ':' builtins do not work
correctly.

For ksh, only the second form fails, eg

#!/bin/ksh
for i in a b c d e f g h
do
	: >$i
done

only creates file 'a'.

The exec variety fails on sh in rather more obscure ways.

Neither of these shells is fixed on the 'Version 3.0' 386 tape, from
a quick look at the code. I have built the sh source and it fails
the test as reported by Randy above.

The reason a 'truss shbug' run from ksh fails is that truss uses execvp
(and hence sh) to invoke the program.

-Malcolm

-- 
Malcolm Mladenovic				mbm@dsbc.icl.co.uk
standard disclaimer applies

In article <20798@uudell.dell.com> jrh@mustang.dell.com (Randy Howard) writes:
 
>Well, that may be true, but the AT&T Release 4.0 Version 3.0 'reference port' 
>or 'Test Engine' as it is sometimes called definitely DOES FAIL.  It is 
>somewhat interesting that if you run it under ksh with: 'truss shbug' it will
>also fail at the same point it does in sh.
>

AT&T Computer Systems Business does not have a 4.0 3.0 'reference port' or
'test engine'.  UNIX System Laboratories does have 4.0 3.0 reference port.
So I guess this bug is in USL's sh.

Note: AT&T UNIX System V/386 Release 4.0 Version 2.1 did have this sh bug
(sorry about the confusion).  However once the AT&T UNIX System V/386 Release
4.0 Version 2.1 Maintenance Disk #1 is applied to the system, the sh bug
is fixed.  The Maintenance disk can be gotten from your AT&T Rep.

Sincerely,

John Ben Urban

jrh@mustang.dell.com (Randy Howard) writes:

>In article <1991May30.171404.23422@cbnewsl.att.com>, urban@cbnewsl.att.com (john.urban) writes:
>|> Your program DOES NOT FAIL on AT&T UNIX System V/386 Release 4.0 Version 2.1.

>Well, that may be true, but the AT&T Release 4.0 Version 3.0 'reference port' 
>or 'Test Engine' as it is sometimes called definitely DOES FAIL.

I just rechecked the bug on our SVR4 Version 2.1 from AT&T and it DOES FAIL.
Which leads me to wonder just how many versions called "2.1" are out there.

I'm also wondering why anyone was messing around with the shell code in
the first place - I mean, if sh is no longer stable, one might as well bite
the bullet and use ksh for the default root shell.

One would hope that the changes made to sh for SVR4 aren't of a major
nature and that the bug can be found simply by diffing the SVR3.2 code
(where it worked) with SVR4.

-Rick
-- 
Rick Richardson		Email: rick@digibd.com
Senior MTS		Fax: (612) 943-0803
DigiBoard, Inc.		Tel: (612) 943-5383

In article <1991Jun05.054111.27541@digibd.com>, rick@digibd.com (Rick Richardson) writes:
|> I just rechecked the bug on our SVR4 Version 2.1 from AT&T and it DOES FAIL.
|> Which leads me to wonder just how many versions called "2.1" are out there.
|> 
|> I'm also wondering why anyone was messing around with the shell code in
|> the first place - I mean, if sh is no longer stable, one might as well bite
|> the bullet and use ksh for the default root shell.

Actually, at Dell we ship ksh as the default shell, I believe the USLSVR4.3 
port mentioned previously does as well.

-- 
Randy Howard                        !'s:uunet!dell!mustang!jrh  
Dell Computer Corp.                 @'s:jrh@mustang.dell.com

jrh@mustang.dell.com (Randy Howard) writes:
>Actually, at Dell we ship ksh as the default shell, I believe the USLSVR4.3 
>port mentioned previously does as well.

While I applaud Dell's efforts, I must be honest an say that they
only reason I discovered this bug was that I tried to install
*production* SVR3.2  code on SVR4 so I code tell the Sales droids
that it would work.  And it didn't.  installpkg shell was run
immediately after login in as root.  Apparently, with sh.
At least on HC? and ATT.  No doubt, Dell is more aware.
And, if ISC, as Principle Publisher, has this bug, we'll all
have a good laugh. :-)  Can't wait! SVR4 3.0 is history. Lets
go for 4. 

-Rick
-- 
Rick Richardson		Email: rick@digibd.com
Senior MTS		Fax: (612) 943-0803
DigiBoard, Inc.		Tel: (612) 943-5383