How will the shell expand an include in a here-doc?

Question

I have a case of twisted shell logic to submit to you, since I have found nothing on that particular point anywhere (please accept my apologies if I missed it). I'll try to explain the context as best I can.

I have a first scriptA which I expect to generate a second scriptB through the use of a heredoc. There are two items I want to have in this heredoc: a my_source file include, and some variables local to scriptA (for expansion within scriptA, that is). Here is an example:

scriptA:

#!/bin/sh
logfile=/path/to/my_logfile
scriptB=/path/to/my_script
cat > ${scriptB} << __EOF__
  . /path/to/my_source  #this is a shell script
  echo "Some text" | tee -a ${logfile}
__EOF__

My question on the snippet above is: will shell expansion on the . instruction (i.e. inclusion of my_source) occur in scriptA or in scriptB?

Bonus: is it possible to specify somehow that some part of the here doc should not be expanded?

Note: I tried to be POSIX-compliant here and avoid bash specifics

Thanks for the insights!

EDIT: Answer is that the . utility shall not trigger in the here-doc in scriptA. This is because a here-doc only performs:

parameter expansion, command substitution, and arithmetic expansion

The . is a shell special built-in utility, which is not expanded (just like all shell built-ins, including bash-, ksh-, tcsh-specific (...) built-ins).

Thanks @ilkkachu for the insight.

Answer 1

No, a here-doc is expanded mostly like a double-quoted string:

If no part of word is quoted, all lines of the here-document shall be expanded for parameter expansion, command substitution, and arithmetic expansion.

Backslashes also work to escape special characters.

The note about quoting means that something like <<"EOF" would prevent expanding anything within the here-doc. In your example, the reference to ${logfile} would be expanded by the shell before passing the input to cat.

You could still use command substitution if you want to include the output of a command, but if all you want is that, using a pipe would also be a logical choice.

Answer 2

The heredoc doesn't do re-interpretation or you can say, doesn't run any commands inside it. It just interpolates strings.

So the answer to your query is that the source-ing will not happen inside the heredoc.

As for the latter, you can make use of \ i.e., backslashes to turn OFF the meaning of characters you don't want expanded by the heredoc.

Answer 3

I know this is super old, but I ran across it one of my searches and wanted to correct it for others.

Here documents can use command substitution with either the backtick ` or using the usual $() notation. So in your case you could source the my_source file using $(. ./my_source).

However, based on your description, I believe you do not really want to source the my_source file. My interpretation of the post is that your intent is to include the content of the my_source file rather than execute the my_source file which would result in its stdout being incorporated into ScriptB.

Instead for posix compliance use command substitution with cat.

#!/bin/sh

logfile=my_logfile
scriptB=my_script
cat > ${scriptB} << __EOF__
  $(cat my_source)  #this is a shell script
  echo "Some text" | tee -a ${logfile}
__EOF__

Command substitution creates a subshell, so if you are ok with bashisms just read the whole file into a variable and then use regular parameter expansion.

#!/bin/bash

logfile=my_logfile
scriptB=my_script
IFS="" read -r -d '' my_source_var < my_source
cat > ${scriptB} << __EOF__
  ${my_source_var}  #this is a shell script
  echo "Some text" | tee -a ${logfile}
__EOF__