Heredocument Error: Delimited by End of File

bashhere-document

I execute the following code in Bash:

bash /dev/fd/10 10<<-'SES'

    cat <<EMR >> /etc/apache2/apache2.conf
        #
        <Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
        </Directory>
        EMR

SES

But the execution breaks and I get:

warning: here-document at line 2 delimited by end-of-file (wanted
`EMR')

I don't understand what the error means and I already added - between the operator and the name of the containing heredoc to allow tabulations.
I made sure there are no spaces after the opener (operator+name) or after the delimiter.

Note: If you copy the code above to test it in your computer, you need to change all leading spaces to tabs (tabulations) as StackExchange changed the original tabulations to spaces.

Possible causes to rule out:

There are several possible causes for this, here are some I've ruled out:

1. Problematic hidden characters:

I edit the file with Notepad++ and I turned on the "Show all symbols" mode to make sure all indents are tabulation based (see red arrows) and that all End Of Line chars (EOLs) are LF unix based (there aren't any CR chars):

Moreover, the encoding is UTF-8, so it's not an encoding problem.

2. Pseudo dash symbol (`<<-`):

It seems as the added hyphen (<<-) doesn't do its job of stripping all leading tabs because when I manually delete all leading tabs whatsoever (or all leading tabs before each delimiter) the heredoc does work as expected. One can suggest that the hyphen isn't really a dash symbol, but why won't it be? I have no way to validate that.

3. Bash bug:

Other people not-using Windows, and using different Bash-containing Linux distros didn't have this, so this is most likely not a Bash bug. I've also tested this with the Bash development section at GNU.

Corrupted pasting of copied data from Notepad++ might be it:

If I paste the heredoc from Notepad++ into a nano file, it seems the leading tabs are all in place – they aren't deleted are transformed into spaces in pasting.

Moreover, cat script.sh | grep "^ " and cat script.sh | grep -x '\s*EMR' (when done in the files directory), come out empty.

Yet, in a later pasting I found another corruption problem that is most likley to cause this (see my answer).

Best Answer

The image you posted shows carriage returns (CR in the image). This is a DOS-formatted text file. Use dos2unix or some similar utility to convert the file to a proper Unix text file.

As per comment below: If you absolutely need to do development in Notepad++ on Windows (I would personally recommend doing the development on the same OS that you're targeting, if at all possible), then the program may be told to save text files with Unix newlines by selecting "Unix (LF)" in the "New Documents" preferences:

Make sure that your file has a newline (LF) at the end of the last line. All lines in a Unix text file (and a shell script is a text file) needs a terminating newline at the end. If the last line doesn't have one, the file is technically actually not a text file but binary.

See also, for example, the answers to "Remove ^M character from log files"

Related Solutions

Bash Script Error – Fixing ‘Unexpected End of File’ in Bash Script

EOJ needs to be fully left-justified, ie. no leading white-space, and no trailing space either. Also, you could/should (depending on your needs) write the first one as <<'EOJ' .. the quotes disable some shell expansion which can otherwise occur.

From info bash

Here Documents This type of redirection instructs the shell to read input from the current source until a line containing only delimiter (with no trailing blanks) is seen. All of the lines read up to that point are then used as the standard input for a command.

   The format of here-documents is:

          <<[-]word
                  here-document
          delimiter

   No  parameter expansion, command substitution, arithmetic expansion, or
   pathname expansion is performed on word.  If any characters in word are
   quoted,  the  delimiter is the result of quote removal on word, and the
   lines in the here-document are not expanded.  If word is unquoted,  all
   lines  of  the here-document are subjected to parameter expansion, com‐
   mand substitution, and arithmetic expansion.  In the latter  case,  the
   character  sequence  \<newline> is ignored, and \ must be used to quote
   the characters \, $, and `.

   If the redirection operator is <<-, then all leading tab characters are
   stripped  from  input  lines  and  the line containing delimiter.  This
   allows here-documents within shell scripts to be indented in a  natural
   fashion.

PuTTY – Pasting Text with Tabs into a Here-Document

When you type into a shell, the shell recognizes some characters as commands. For example, the carriage return character (the character sent by the Enter key) causes the shell to execute the command. The tab character causes the shell to perform completion. When you paste something into the PuTTY terminal window, from the shell's point of view, that's the same thing as if you'd typed these characters. So at the point the tab character is pasted, the shell performs completion, it doesn't insert a tab.

The easiest way to copy a file without it being transformed would be to use PuTTY's companion program PSCP or PSFTP to copy the file. This is the simplest way conceptually, but it does have the overhead of running another program, authenticating, choosing a directory, etc.

If you want something inline, you can paste directly into cat, rather than in a here document. Then you'd be pasting into the terminal's line editor, not into the shell's line editor. As the terminal's line editor is very primitive, only a few control characters have a special meaning there, not including tab. Press Ctrl+D at the beginning of a line to terminate the input.

[darkstar /]$ cat >text.txt
Paste
Ctrl+D
[darkstar /]$

I you want to transfer arbitrary data over a medium that interprets control characters, you can encode it into a form that uses only “tame” characters. Base64 is one; it doesn't use any control character and ignores whitespace and newlines. GNU coreutils, which is part of the basic installation on Linux and Cygwin, includes a base64 command. On the sender side, run base64 <file-to-decode, e.g.

On Windows: run base64 c:/path/to/test.txt from a Cygwin terminal
Copy the output.
In the shell in the PuTTY window, type `base64 -d >/tmp/test.txt and press Enter.
Paste the output from base64.
Press Ctrl+D.