Re: Here documents

[Paul Haahr <haahr@mv.us.adobe.com>]

>	1. Can someone provide a more definitive definition of the
>	source of here documents.

here documents are always read from the same place as where commands are  
read.  they are also read at parse time, not execution time.  this is done  
to support here docs in functions and loops, which i believe are not  
supported by td's rc.  (use rc -nx to explore what's going on:  heredocs get  
turned into here strings.)

	;; rc -nx
	; cat << EOF
	hello, $USER
	EOF
	cat <<<'hello, '^$^USER^'
	'
	; 


>	2. Should a here document be read from rc's stdin, rather than the
>	source of its commands?  Would this break any existing scripts?  

>	This would allow example [3] to work.

no, that's what redirection, pipes, and normal standard input processing do.   
it would break just about every script.

>	3. Should a here document be read from a command's stdin,
>	rather than the shell input?  Would this break any existing scripts?
>	This would allow example [2] to work.

no, for the same reasons.

----

as to your examples, i don't see why you're using here docs:

>	[2]	; { echo '$foo' ; echo EOF } | cat <<EOF
>	[3]	; { echo '$foo' ; echo EOF } | rc -c 'cat <<EOF'

why not

	echo $foo | cat

or (if you insist on using heredocs)

	cat << EOF
	$foo
	EOF

both of which seems to do what you want.

>	[4]	; { echo 'cat <<EOF' ; echo '$foo' ; echo EOF } | rc

here you're doing exactly what rc is not supposed to do:  parsing the same  
data twice, in this case by two separate shells.  (you could actually do  
something similar with eval, but the idea is the same.)

it seems that you want to take the output of some program, containing  
references to shell variables, expanded by the heredoc machinery.  that does  
seem like an appropriate use of a second shell, in which case example 4 is  
the way to go.

> I am intrigued that such subtleties exist in an apparently
> straightforward feature of the language.

heredocs don't fit naturally into the model of the rest of the shell, but  
are so useful as to warrant an exception.  i think byron's solution (here  
strings and conversion at parse time) is elegant and clever, and, when  
understood, makes the answers to ``what if?'' questions obvious.