Re: Here documents

[Alan Watson <alan@oldp.astro.wisc.edu>]

Paul writes:

> heredocs get turned into here strings

Ah, finally a justification for here strings (my number three
candidate for elimination from rc after ` without {} and ``{}).

>>       2. Should a here document be read from rc's stdin, rather than the
>>       source of its commands?  Would this break any existing scripts?
>
>no, that's what redirection, pipes, and normal standard input processing do.
>it would break just about every script.

I was thinking more of interactive invocations of rc (or, perhaps more
accurately, I was emphatically not thinking about scripts).  A better
suggestion would be that if we are at EOF on the source of command
input, a here document should be read from stdin; this would allow my
example [3] to work.

Byron writes:

> As to your question about whether input should be read from stdin
> "if there's a redirection of stdin". What does this mean? 

I mean that when I specify both a redirection of stdin (by putting a
pipe in front of a command or using an explicit `<') and a here
document, that the here document should be read from the source of
stdin.  In concrete terms, this would take a hypothetical:

	; foo | bar <<EOF

and transform it into:

	; { { echo 'cat <<EOF' ; foo } | rc } | bar

> In general,
> it's not possible to tell if there's a redirection of stdin.

Really?  Yes, rc cannot tell if its stdin has been redirected, but
surely it can tell if it is asked to redirect the stdin of a command.
Perhaps not, as rc does not fault any of:

	; cat foo | cat <bar
	
	; cat >foo | cat

	; cat <foo <bar

	; cat >foo >bar

for having multiple redirections of stdin and stdout.  To be honest, I
would be happiest if rc had issued error messages for my examples [2]
and [3], but from Byron's statement this would appear to be
impossible.  I have to say I am somewhat surprised.

Perhaps Byron's description of the source of here documents should be
added to the man page, just for completeness.

Alan.