rick@digibd.com (Rick Richardson) (05/30/91)
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.
#
# 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-5383urban@cbnewsl.att.com (john.urban) (05/31/91)
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
jlitvin@morticia.intel.com (John Litvin ~) (05/31/91)
>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
jrh@mustang.dell.com (Randy Howard) (06/01/91)
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
mbm@dsbc.icl.co.uk (Malcolm Mladenovic) (06/01/91)
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
urban@cbnewsl.att.com (john.urban) (06/03/91)
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
rick@digibd.com (Rick Richardson) (06/05/91)
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
arnold@audiofax.com (Arnold Robbins) (06/05/91)
In article <1991Jun05.054111.27541@digibd.com> rick@digibd.com (Rick Richardson) writes: |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. Amen. There's no reason to ship *three* stupid shells. ksh should have been installed as /bin/sh and that's it. |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. Well, if adding job control to sh isn't major, I don't know what is..... -- Arnold Robbins AudioFAX, Inc. | Threads are the 2000 Powers Ferry Road, Suite 200 / Marietta, GA. 30067 | lack of an idea. INTERNET: arnold@audiofax.com Phone: +1 404 618 4281 | -- Rob Pike UUCP: emory!audfax!arnold Fax-box: +1 404 618 4581 |
jrh@mustang.dell.com (Randy Howard) (06/06/91)
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
rick@digibd.com (Rick Richardson) (06/09/91)
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
bdb@becker.UUCP (Bruce D. Becker) (06/13/91)
In article <377@audfax.audiofax.com> arnold@audiofax.com (Arnold Robbins) writes: |In article <1991Jun05.054111.27541@digibd.com> rick@digibd.com (Rick Richardson) writes: ||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. | |Amen. There's no reason to ship *three* stupid shells. ksh should have |been installed as /bin/sh and that's it. Agreed - so how about it Amiga unix guys, we all know it works; will you do this for the 2.0 release? -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!utai!mnetor!becker!bdb _< /_ "Ferget yer humanity, do the poot" - devo