Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1a 7/7/83; site rlgvax.UUCP
Path: utzoo!linus!philabs!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.unix-wizards
Subject: Re: sh bug
Message-ID: <1206@rlgvax.UUCP>
Date: Tue, 27-Sep-83 01:43:07 EDT
Article-I.D.: rlgvax.1206
Posted: Tue Sep 27 01:43:07 1983
Date-Received: Wed, 28-Sep-83 23:49:28 EDT
References: <774@bronze.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 56

1) The description of the shell bug:

        "If << is used to provide standard input to an asynchronous
        process invoked by &, the shell gets mixed up about naming
        the input document.  A garbage file /tmp/sh* is created,
        and the shell complains about not being able to find the
        file by another name."

is incorrect.  The correct version is:

	"If << is used to provide standard input to an asynchronous
	process invoked by &, the parent shell deletes a temporary
	file needed by the child shell executing the command.  A garbage
	file /tmp/sh* is created, and the shell complains about not
	being able to find the temporary file."

2) Yes, I *tried* fixing it, by having the child shell delete the temporary
file.  The trouble is that you can construct a pathological case in which
neither the parent nor the child shell knows the right time to delete the
temporary file.

"Here documents" which are to have shell variable and `` expansion performed
are done with two files.  The shell makes a literal copy of the text of the
here document at the time the command line is parsed.  Each time the command
is to be executed, the shell reads from the literal copy, expanding variables
and ``s, and writes the expanded copy to another file.  Then the command is
run with its standard input redirected to the expanded copy.  Now, take the
command:

while (something)
do
	command <<EOF &
This is a $test.
EOF
done

The child process (i.e., the one that's going to run the command "command") is
the one that makes the expanded copy of the here document.  Since the
command is going to be executed in a loop, however, it can't delete the literal
copy after it does the expansion because it may be needed next time around
the loop.  The parent knows when it's done with the loop; however, it does
not know when the last child process has opened the literal copy, so it can't
delete the literal copy after the last pass through the loop.  After discovering
this I gave up; does anybody see a way out?  The C shell solves the problem
by reading the literal copy directly from the shell file, which is presumably
not deleted by the shell.  I don't remember how it handles the case of when
the loop is typed at the terminal.

Since the same bug is listed in the 5.0 manual, I suspect nobody's come
up with a fix yet; since it has the same statement of the bug, it is
conceivable that nobody in the USG has looked into it.  If anybody's fixed
it, please let us all know; I have to create a lot of trash temporary files
because I want to kick off loops in the background like that.

	Guy Harris
	{seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy