0

I've looked at these posts:

but it doesn't answer conceptually why not.

For example:

#!/bin/bash

echo \
# comment
-n hello

on shellcheck.net yields:

-n hello ^-- SC2215 (warning): This flag is used as a command name. Bad line break or missing [ .. ]?

Reason I thought it would be okay:

  • I had learned comments are ignored by programs (and so it should make no difference)

For example, a C program:

#include <stdio.h>

int main() {

  printf("hello%d\n",
         // my comment
         3);
}

Why is this fundamentally different in bash and sh?

How is it being interpreted that causes this (with comments not being completely ignored by the interpreter)?

My idea:

  • the shell simply ignores lines with comments while parsing, but expects a continuation line after the backslash and for some reason (why?) breaks if a comment (which should be ignored) is there instead of looking at the next (uncommented) line
  • C compiler never even sees comments because they are gone by compilation stage
user129393192
  • 797
  • 1
  • 8
  • 1
    A comment starts with a `#` character and extends to the end of the line. Provided that you have neither a `$` nor a `;` in your comment, you could use the no-op command `:` which simply ignores all arguments, and use this as a poor man's comment. Example: `echo x; : this is a comment; echo y` – user1934428 May 17 '23 at 06:42
  • 1
    As an explanation: From my understanding, The commented area starts at the `#` end ends right before the _newline_ character. Therefore, a `# ....` still leaves the final newline after the comment is removed. In your example, this makes `-n hello` strart in a new line. In C++ however, the `//` comment seems to extend up to **including** the newline character. – user1934428 May 17 '23 at 06:53
  • it's not about why or why not. it's more about choices/decisions people made at some time. you can write your own shell to support it. and if you have enough power you can make new standards. – pynexj May 17 '23 at 07:20

1 Answers1

1

For POSIX shell, this behaviour is defined here in chapter 2.3 Token Recognition:

If the current character is a '#', it and all subsequent characters up to, but excluding, the next newline shall be discarded as a comment. The newline that ends the line is not considered part of the comment.

bash simply took over this convention to make it easier to port scripts from sh to bash. From what I see, zsh is doing the same, and most likely ksh too.

user1934428
  • 19,864
  • 7
  • 42
  • 87
  • Thanks for your explanation. So the best solution is to have comments as `: … \\` then? I wonder if you could also have the `\\` in there after a `#`. – user129393192 May 17 '23 at 19:59
  • @user129393192:Let's put it like this: The shell does not provide for comments **inside** a command (like `/* .... */` construct of C. This in not related to whether the command is on a line of its own, or stretches several line. In your concrete `echo` example, you could write the comment as `${CommenT:+this is a comment}`. As long as you ensure that you don't have a variable named `CommenT`, the shell will expand this to an empty string (due to the `:+`) and the `echo` will display only _hello_. However, I would consider this a hack. Better place your comment into a line, where it's OK. – user1934428 May 19 '23 at 06:14
  • @user12939192 : With other words: If you want to hack the design philosophy of a programming language, you have to think of a suitable solution on a case by case base. The idea of using a dummy variable `CommenT` will work often, but is ugly. In other situations, you could use the no-op command `: .... ` to achieve a similar effect. But fighting the way a programming language is designed to be used, will in the end give you headache and doesn't make your code easier to maintain. – user1934428 May 19 '23 at 06:18