Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!icom!xwkg.Icom.Com!andy
From: andy@xwkg.Icom.Com (Andrew H. Marrinson)
Newsgroups: comp.bugs.sys5
Subject: Nasty bug in release 4 Bourne shell
Summary: Using null execs to redirect I/O in a while loop loses!
Keywords: Bourne shell, exec, redirection
Message-ID: <andy.662338820@xwkg>
Date: 27 Dec 90 23:00:20 GMT
Sender: news@icom.icom.com (News Feed)
Organization: Icom Systems, Inc.
Lines: 41

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)