On 11/17/21 3:02 PM, Robert Elz wrote:
> | bash-5.1$ cat << $PATH
>
>
> | it should have terminated with the upper delimiter!
>
> What do you consider the "upper delimiter" ?
>
> This is one of the weirder aspects of shell syntax, and perhaps one
> of bash's oddities.
It's not. Every modern shell uses `$PATH' as the here-document delimiter
and checks for the delimiter before any part of the process that expands
the lines in the here-document body.
> First, the EOF should not work, that's a bash bug (IMO) - that should
> generate an error, not just a warning.
It's not. The historical shells used for the basis of the POSIX standard
(ksh88 and the SVR4 sh) silently allow EOF to terminate a here-document;
ksh93 preserves this behavior. Some of the common shells allow this as
well (e.g., dash, zsh and the version of the FreeBSD from a couple of years
ago when I last built it), some do not (e.g., mksh and the netbsd sh). Bash
at least warns you about it.
>
> Example:
> |
> | bash-5.1$
> | bash-5.1$ cat << ola"
>
> OK, here we have another of the oddities of shell syntax. The spec
> says that a here document starts at the next newline after the << operator,
> but that's not what it really means.
I think the intent there is that the here document starts at the next
newline after the delimiter.
> Being able to do that (include embedded newline characters
> in a "line") isn't required by the shell specification, and (it has been
> a while since I checked) I do not believe that those work in bash (they
> do in some other shells).
I couldn't fine one where it does.
> Since bash doesn't allow end delimiter words that contain newlines to
> work, it should probably generate an error when you try to use one, that
> would have made things clear.
See above.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
