Re: Here documents

Re: Here documents

[Byron Rakitzis]

>Ah, finally a justification for here strings.

Sorry, but it's in TFM:

     (This feature enables rc  to  export  functions  using  here
     documents  into  the environment; the author does not expect
     users to find this feature useful.)

Re: Here documents

[Scott Merrilees]

I expect here documents to be part of the shell syntax stream,
rather than part of the shell data stream.

Thus it did not occur to me that something like the following would
be even conceivable:

	{ echo ...; echo ...; echo EOF } | cat << EOF

as for multiple redirection in the same command, this doesn't bother
me as long as it is done left->right.

So I should be able to do

	cmd >file1 >[9=1] >[1=2]

Sm

Re: Here documents

[Alan Watson]

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.

Re: Here documents

[Paul Haahr]

>	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.

Re: Here documents

[Alan Watson]

Obviously, my question 3 should be prefaced by `When a command has
both a here document and a redirection of stdin, should the here
document be read from the command's stdin?'  This prevents the current
behaviour of here documents in scripts from changing.

Alan.

Here documents

[Alan Watson]

I was playing around with here documents, trying to get environment
variable substitution within a file, when I noticed the following:

[1]	; foo=bar
	; cat <<EOF
	foo
	EOF
	bar
	;

but if I try:

[2]	; { echo '$foo' ; echo EOF } | cat <<EOF

then rc ignores the pipe and attempts to read from the terminal.  This
is all well and good, as the rc manual page states:

       ``Here documents'' are supported as in sh with the use of

	  command << 'eof-marker'

and my man page for sh (under Ultrix 4.3: hardly definitive) states:

     <<word
	  The shell input is read up to	a line the same	as word, or end of
	  file.	 The resulting document	becomes	the standard input.  

and one can argue that the `shell input' is not the same as the
standard input to the cat command.  However, the following is more
interesting:

[3]	; { echo '$foo' ; echo EOF } | rc -c 'cat <<EOF'
	line 1: heredoc incomplete near EOF

Clearly, the `shell command input' is the string `cat <<EOF', but is
this the same as the `shell input'?  The following code achieves my
purpose:

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

I now have several questions:

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

	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.

	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.

Perhaps the answers are obvious and of no interest to anyone else, but
I am intrigued that such subtleties exist in an apparently
straightforward feature of the language.

Alan Watson.

Here documents

[raymondc]

: { echo 'cat <<EOF' ; echo '$foo' ; echo EOF } | rc

Which can much more readably be written as

	rc -c 'cat <<EOF
	$foo
	EOF
	'
	
:	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.

I vote no.  Here documents should be read from the shell input.
(I.e., the place the did the "<<" or "<<<".)

Otherwise, you can't do stuff like...

	# xpend -- prepend and append goop

	cat <<EOF			# add the header
	------------------------------------------------------------
	Item $1
	------------------------------------------------------------
	EOF
	cat				# let the body pass through
	cat <<EOF			# add the footer
	------------------------------------------------------------
	End of item $1
	------------------------------------------------------------
	EOF

If the here document took its input from stdin instead of
the shell command input, this script would break.

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

Here documents (and really-here documents) take their input from
the shell command input; i.e., the place where shell commands are
parsed and executed.  I see no subtleties.  Here documents are
merely a handy abbreviation for a huge sequence of "echo"s.
--
Raymond (FOB --- Friend of Byron) Chen