You should also fix the shebang. The first line needs to be literally #!/bin/bash and nothing else -- the #! is what makes it into a valid shebang line, and what comes after it is the path to the interpreter.
– tripleeeJan 5 '15 at 5:15

3 Answers
3

You only need a minimal change; single-quote the here-document delimiter after <<.

cat <<'EOF' >> brightup.sh

or equivalently backslash-escape it:

cat <<\EOF >>brightup.sh

Without quoting, the here document will undergo variable substitution, backticks will be evaluated, etc, like you discovered.

If you need to expand some, but not all, values, you need to individually escape the ones you want to prevent.

cat <<EOF >>brightup.sh
#!/bin/sh
# Created on $(date # : <<-- this will be evaluated before cat;)
echo "\$HOME will not be evaluated because it is backslash-escaped"
EOF

will produce

#!/bin/sh
# Created on Fri Feb 16 11:00:18 UTC 2018
echo "$HOME will not be evaluated because it is backslash-escaped"

As suggested by @fedorqui, here is the relevant section from man 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, command substitution, and arithmetic expansion. In the
latter case, the character sequence \ is ignored, and \
must be used to quote the characters \, $, and `.

I see you marked How to avoid heredoc expanding variables? as a duplicate of this one. No objections, only that I would include the Bash docs reference, as I did in mine (which having only 13k visits got almost 100 rep, so it seems to be quite helpful).
– fedorquiJun 6 '18 at 9:57

@fedorqui Maybe you want to port your answer to this question actually? Or we can switch the duplicate marking to be the other way around; I just looked at the question score, not the answer scores much.
– tripleeeJun 6 '18 at 10:08

Mmm what about merging them, having this one as the target question? The duplicate question has a good title, only that it is toooo long. However, it somehow got quite a lot of attention out of late (I am getting some upvotes per month).
– fedorquiJun 6 '18 at 10:32

@fedorqui I like the concept of merging but I have never seen it happen in practice; if I understand the situation correctly, the mods are simply not able to handle nontrivial merges because the hassles and complexities far outweigh the benefits. What I've done once or twice is delete an useful and upvoted answer and reposting it under a different question, though I can hardly recommend this workaround.
– tripleeeJun 6 '18 at 10:53

It is hard to tell when it is worth doing. I've done it in a site I mod when a good question was posted without noticing there was another good one from before, both having good answers. Removing my 90+ score answer does not seem a good plan, since it would leave that question orphan.
– fedorquiJun 6 '18 at 11:50

This should work, I just tested it out and it worked as expected: no expansion, substitution, or what-have-you took place.

cat <<< '
#!/bin/bash
curr=`cat /sys/class/backlight/intel_backlight/actual_brightness`
if [ $curr -lt 4477 ]; then
curr=$((curr+406));
echo $curr > /sys/class/backlight/intel_backlight/brightness;
fi' > file # use overwrite mode so that you don't keep on appending the same script to that file over and over again, unless that's what you want.

Using the following also works.

cat <<< ' > file
... code ...'

Also, it's worth noting that when using heredocs, such as << EOF, substitution and variable expansion and the like takes place. So doing something like this:

cat << EOF > file
cd "$HOME"
echo "$PWD" # echo the current path
EOF

will always result in the expansion of the variables $HOME and $PWD. So if your home directory is /home/foobar and the current path is /home/foobar/bin, file will look like this:

A here string in single quotes obviously cannot contain any single quotes, which may be a prohibitive issue. Here documents are the only sane workaround if you have a script which needs to contain both single and double quotes, although that is not of course the case with the OP's simple example. Also, tangentially, here-strings <<< are only available starting from Bash 3, and not portable to other shells.
– tripleeeJun 26 '15 at 3:23

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).