zsh comment character

Question

Many bash scripts invoke the #character to indicate a comment. Catalina migrated to zsh. The command:

# Comments should elicit no response

returns

zsh: command not found: #

I find useful command examples on the web: it is helpful to annotate commands with said #weblink so that it is captured in the history.

I did find this post: https://stackoverflow.com/a/11873793/4953146

1. Is there a reason for the # not to be recognized as the comment character in zsh?
2. How can the terminal be configured to recognize the character as a comment?

Question 1 sets the context for deciding on a method to address question 2. It would nice to be able to configure the character once and all future instances of zsh would follow. If there is / was a good reason why the feature was disabled, I would like to understand any reasons.

Understanding the 'why' is important to determine the 'how'. There seems to be many ways to restore # commenting in zsh. One durable solution is to add to the configuration file: sudo vi /etc/zshrc:

setopt interactivecomments

Other methods (not durable) include invoking ksh or sh.

Many thanks to user3439894 & Allan for supporting / advancing the question.

Answer 1

This is due to how Bash/Zsh is configured to handle comment characters in interactive and non-interactive shells.

Normally, comment characters are not recognized in interactive shells by default, so this behavior is normal.

From the Bash Reference Manual, Chapter 3.1.3 - Comments:

In a non-interactive shell, or an interactive shell in which the interactive_comments option to the shopt builtin is enabled , a word beginning with ‘#’ causes that word and all remaining characters on that line to be ignored. An interactive shell without the interactive_comments option enabled does not allow comments. The interactive_comments option is on by default in interactive shells.

The difference between interactive and non-interactive shells is that in the former, input and output is via the user's terminal whereas in the latter commands are asynchronous (no interaction). Though you are in an interactive shell, when you start a script, a non-interactive subshell is created.

• Interactive Shells (Chapter 6.3)
• Command Execution Environment (Chapter 3.7.3)

Though I've referenced Bash in this answer, Zsh is the same. Chapter 6.7 - Comments reads almost the same:

In non-interactive shells, or in interactive shells with the INTERACTIVE_COMMENTS option set, a word beginning with the third character of the histchars parameter (‘#’ by default) causes that word and all the following characters up to a newline to be ignored.

---

If there is / was a good reason why the feature was disabled, I would like to understand any reasons.

I hesitate to use the word "disabled" as it's merely an environment variable that sets up the execution environment; it's simply "not set" by default. There's no documentation as to the reasoning why Apple (ultimately) chose to set it.

I can confirm that in other operating systems I've tested (FreeBSD and Debian), I installed Zsh (v5.8) and in both, the behavior described is the same as it is here - it's not set. This points to a decision by the Zsh folks that this was their preferred behavior of the execution environment. As we can't speculate as to why Apple did something, it's even more difficult to speculate why Zsh did/didn't do something and why Apple didn't modify it. Though it's probably a safe bet that Apple just went with the defaults.

Answer 2

I disagree with this answer. It is not a matter of going with defaults. ("Apple just went with the defaults."), but a matter of features.

In zsh the # symbol works like a regexp quantifier, providing extended globbing. So

ls fo#                                                                                                         

matches the files:

f fo foo

and so on, that is zero or more o. While the double # matches one or more characters, that is:

ls fo##

matches

fo foo

While for interactive use this type of globbing is convenient, in a script it is better to use proper regexps. In particular, ls is discouraged for scripts, because it cannot be parsed reliably, in favour of find, which sports a -regex option to execute a command for each matching path.

Because in (long) scripts comments are necessary, but we can do without hash-globbing, they are activated. Instead, in interactive use, it is assumed that the benefits of globbing outweigh the lack of comments.

In Bash, there is no such a globbing feature, so it is conveninent to always have the commenting #. However, you can restore the interactive comments in zsh too with:

setopt interactive_comments

In this case, given:

ls fo#
ls fo # this is a comment 

the first # works as a glob, the second after a space, is a comment.
You can also disable extended globbing altogether with:

unsetopt extended_glob

That being the case, and while zsh is in many ways superior to Bash, replacing Bash with zsh was a poor design choice. In fact, zsh differs from Bash in several subtle ways, and your collection of one-liners might not work as expected. Microsoft adopted a better approach when introducing their new shell: it was not the new default, but just a new (better) alternative.

Answer 3

Not an answer but a work-around:

The bash/zsh do-nothing built-in command, :, can be used for simple end-of-line comments. Beware though, because it is a command, not a comment, (a) you need to precede it with a ; and (b) it expands its arguments. So, for example, : ... $(rm foo) or : ... ; rm foo will execute the command rm foo, which may not be what the reader is expecting.