C-shell fix: too many prompts spoil the code

[utzoo!decvax!duke!chico!harpo!cbosg!teklabs!tekmdp!azure!randals]

The cshell (according to the documentation, or at least most of the
conventions) set the variable "prompt" whenever it needed to output
a prompt.  This generally was assumed to be whenever interactive input
was being taken.  However, the cshell missed one case in its checks
for whether or not to set a prompt: when commands were being read from
"stdin", it still set it.  This made command lines like
	echo foo | csh
or
	csh <<EOF
	foo
	EOF
set the prompt anyway.  The fix is as follows (the line number is
approximate; we've made some other mods too):

	[ around line 220 in sh.c ]
	/*
	 * Consider input a tty if it really is or we are interactive.
	 */
	intty = intact || isatty(SHIN);
+++	/*
+++	 * If the input is not a tty, we DEFINITELY don't need a prompt.
+++	 */
+++	if (!intty)
+++		prompt = 0;
	/*
	 * Decide whether we should play with signals or not.
	 * If we are explicitly told (via -i, or -) or we are a login
	 * shell (arg0 starts with -) or the input and output are both
	 * the ttys("csh", or "csh</dev/ttyx>/dev/ttyx")
	 * Note that in only the login shell is it likely that parent
	 * may have set signals to be ignored
	 */

Lines flagged with "+++" are new.  I found the problem when I put
some magic code in my .cshrc to do some things when I'm interactive
(like set the mail and time variables) and some other things when
I'm not.  When I queued up a file for "at" (which feeds stuff via
stdin to the cshell), my time and mail variables were set!  [The
magic of software... I will never cease to be surprised.]

A brief disclaimer... this new line of code has not had a lot of mileage
put on it... we've only had it installed for a short time.  No warranties
for fitness of use are expressed or implied.  Should you be caught using
this code, the Secretary of State will disavow all your actions, and issue
some incomprehensible press release stating some horrendous obfuscations.

Randal L. Schwartz
Tektronix Microcomputer Development Products
Beaverton, Oregon (OR-ee-gun... not awww-ru-GONE!!)