Xref: utzoo comp.unix.shell:2295 comp.unix.wizards:25800 comp.unix.sysv386:8577
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!cbnewsl!urban
From: urban@cbnewsl.att.com (john.urban)
Newsgroups: comp.unix.shell,comp.unix.wizards,comp.unix.sysv386
Subject: Re: SVR4 /bin/sh BUG Summary
Message-ID: <1991May30.153352.18950@cbnewsl.att.com>
Date: 30 May 91 15:33:52 GMT
References: <1991May29.162012.25888@digibd.com>
Organization: AT&T Bell Laboratories
Lines: 48

In article <1991May29.162012.25888@digibd.com> rick@digibd.com (Rick Richardson) writes:
>I recently posted the enclosed script which demonstrates a
>bug in SVR4's Bourne shell.  With the help of the net,
>it appears that the bug is not restricted to just one
>architecture.  Failure has been reported on:
>

I thought I had replied to you before, but perhaps I forgot or it got lost.

This BUG does NOT exist on:
AT&T UNIX System V/386 Release 4.0 Version 2.1.  Both KSH and SH work fine
on the example.

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