50

Consider

echo \ # this is a comment
foo

This gives:

$ sh foo.sh
 # this is a comment
foo.sh: line 2: foo: command not found

After some searching on the web, I found a solution by DigitalRoss on sister site Stack Overflow. So one can do

echo `: this is a comment` \
foo

or alternatively

echo $(: this is a comment) \
foo

However, DigitalRoss didn't explain why these solutions work. I'd appreciate an explanation. He replied with a comment:

There used to be a shell goto command which branched to labels specified like : here. The goto is gone but you can still use the : whatever syntax ... : is a sort of parsed comment now.

But I'd like more details and context, including a discussion of portability.

Of course, if anyone has other solutions, that would be good too.

See also the earlier question How to comment multi-line commands in shell scripts?.


Take home message from the discussion below. The `: this is a comment` is just a command substitution. The output of : this is a comment is nothing, and that gets put in the place of `: this is a comment`.

A better choice is the following:

echo `# this is a comment` \
foo

3 Answers 3

38

Comments end at the first newline (see shell token recognition rule 10), without allowing continuation lines, so this code has foo in a separate command line:

echo # this is a comment \
foo

As for your first proposal, the backslash isn't followed by a newline, you're just quoting the space: it's equivalent to

echo ' # this is a comment'
foo

$(: this is a comment) substitutes the output of the command : this is a comment. If the output of that command is empty, this is effectively a highly confusing way to insert a comment in the middle of a line.

There's no magic going on: : is an ordinary command, the colon utility, which does nothing. The colon utility is mostly useful when the shell syntax requires a command but you happen to have nothing to do.

# Sample code to compress files that don't look compressed
case "$1" in
  *.gz|*.tgz|*.bz2|*.zip|*.jar|*.od?)
    :  # do nothing, the file is already compressed
    ;;
  *)
    bzip2 -9 "$1"
    ;;
esac

Another use case is an idiom for setting a variable if it's not already set.

: "${foo:=default value}"

The remark about goto is a historical one. The colon utility dates back from even before the Bourne shell, all the way to the Thompson shell, which had a goto instruction. The colon then meant a label; a colon is a fairly common syntax for goto labels (it's still present in sed).

7
  • Ok, I see. Are there any one better ways of inserting comments in this context that you are aware of? Aug 21, 2011 at 16:05
  • 3
    @FaheemMitha As recommended in the thread you cite: break up your command into manageable chunks and comment each chunk. If your command is so complicated as to need a comment in the middle, it's time to simplify it! Aug 21, 2011 at 16:15
  • 2
    Well, the command in question has a lot of arguments... It's converting a bunch of video files into one file. I don't see a direct way to simplify it. Maybe create a list of some sort, and pass it as an argument? I guess that could be another question. Aug 21, 2011 at 16:19
  • @FaheemMitha Example: make_FIND, a quickie script which builds a long list of arguments to find. Here, the motivation for building it chunk by chunk is that each chunk comes from the body of a loop, but the same style allows to comment on each chunk. Aug 21, 2011 at 17:46
  • 1
    Thanks for the example. My example is basically just a long list of names given as arguments to a command. I want comments attached to each name, because that is the most easy way for me to keep context. I don't see any obvious way to break the command up into pieces, and if I did, it might make it even longer, and it is long enough already. Aug 21, 2011 at 18:42
21

You can achieve this using Bash arrays, e.g.

#!/bin/bash
CMD=(
  echo  # this is a comment
  foo
  )

"${CMD[@]}"

This defines an array, $CMD, and then expands it. Once expanded the resulting line is evaluated, so in this case echo foo is executed.

The text between ( and ) defines the array and is subject to the usual bash syntax, so everything on a line after # is ignored.

Note about preserving command and arguments

${CMD[@]} expands the elements of the array without preserving characters within each element that would otherwise be interpreted by the shell, such as space or globbing punctuation. Once expanded, Bash would then parse all found tokens in the usual manner (c.f. $IFS), which is usually not what we want.

By contrast, if the expansion is wrapped in double quotes, i.e. "${CMD[@]}", then each element in the array is preserved. Consider the difference between hello world second item and "hello world" "second item".

Illustrative example:

$ LIST=("hello world" "second item")

$ for ITEM in ${LIST[@]}; do echo $ITEM; done
hello
world
second
item

$ for ITEM in "${LIST[@]}"; do echo $ITEM; done
hello world
second item
2
  • Thank you for the answer, @RobM. So, your suggestion is to include the comments/meta-information about the items in the list in the bash array itself? This question would probably be more useful if I had included an example of the kind of command I was trying to use. I don't know why I didn't. Apr 5, 2015 at 16:50
  • Bah, it turns out I didn't read your question carefully. Thought you were asking the question you linked to. Oops. :)
    – RobM
    Apr 10, 2015 at 17:32
10

Don't do $(: comment). That's not a comment - that's a subshell - another whole new shell process for most shells. Your goal is to do less w/ your input, not more, which is what that would do - even if it is pointless.

You can instead do...

printf '<%s>\n' some args here ${-##*"${--

                my long comment block

                }"}  and "more ${-##*"${--

                and another one in the
                middle of the quoted string
                there shouldn\'t b\e any special &
                (character) `echo issues here i hope >&2`
                basically anything that isn\'t a close \}
                $(echo the shell is looking for one >&2)
                }$(echo "}'"\" need backslash escaping >&2
                                )${-##*${--

                nesting is cool though

             }}"}here too"

}'" need backslash escaping
<some>
<args>
<here>
<and>
<more here too>

Basically what's happening there is the shell is doing a substitution. It substitutes the value of the special shell parameter $- twice each time. It's a short string anyway, but it is always set - and so the inner substitution - which is interpreted as a pattern to strip from the outer - doesn't expand to the contents between the parentheses when I use the - expansion form.

Here:

bash -x <<""
printf %s\\n '${-##*"'${-- a set param doesn\'t expand to this optional text }'"}'

+ printf '%s\n' '${-##*"hxB"}'
${-##*"hxB"}

See? So it's just expanded twice. As soon the shell finds the parameter is set everything in the optional expansion field is discarded, pretty much, and it expands to its whole value which is removed from itself and so to nothing at all. In most shells you need not even escape quotes, but bash requires it.

Better still is:

COMMENT=
echo      ${COMMENT-"
           this will work the same way
           but the stripping isn\'t
           necessary because, while
           the variable is set, it is also
           empty, and so it will expand to
           its value - which is nothing
           "} this you\'ll see

this you'll see

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .