Re: bug report: INTERACTIVECOMMENTS option interacts oddly with shell functions in an interactive context

[Stephane Chazelas <stephane@xxxxxxxxxxxx>]

2021-08-31 20:41:57 -0700, Bart Schaefer:
> On Mon, Aug 30, 2021 at 11:03 PM Stephane Chazelas
> <stephane@xxxxxxxxxxxx> wrote:
> >
> > But that used to work OK, up to 5.4.1 at least, and also applies
> > to echo $(#comment) outside of functions.
> 
> +Changes from 5.4 to 5.4.3
> +-------------------------
> +
> +The effect of the NO_INTERACTIVE_COMMENTS option extends into $(...) and
> +`...` command substitutions when used on the command line.  Previously,
> +comments were always recognized within command substitutions unless the
> +comment character "#" was disabled via reset of $histchars.
> 
> Thread started with workers/41656 (September 2017) about writing
> aliases that start with "#" and being able to use them inside $(...).

Thanks.

That still leaves a few problems:

First and more important, comments are meant to be stripped in
scripts, whether they're executed or sourced, whether that's
from an interactive shell with interactivecomments or not.

If not, you wouldn't be able to have comments in any script you
intent to source other than by adding something like  
set -o interactivecomments at the beginning (and restoring upon
return).

So here, I'd say:

~$ cat a
echo foo # comment
echo $(
  echo bar # comment
)
~$ . ./a
foo
./a:3: bad pattern: #

is clearly a bug (regression).

Once that's fixed there's still the problem of delayed (second)
parsing of code inside command substitution. Which would still
cause functions defined in sourced scripts to fail (or behave
differently) when invoked from interactive shells.

It seems to me the interactivecomments option should be honoured
at time of reading code, and comments stripped then when it's
on.

$ set -o interactivecomments
~$ f() {
echo foo # comment
echo $(
echo bar # comment
)
}
~$ f
foo
bar
~$ set +o interactivecomments
~$ f
foo
f:3: bad pattern: #

$ which f
f () {
        echo foo
        echo $(
echo bar # comment
)
}


IMO, that function f should have been stored as:

$ which f
f () {
        echo foo
        echo $(
echo bar
)
}

As already noted, there's also a consistency problem in that
while comments are no longer stripped in command substitutions
with interactivecomments off, they still are in process
substitutions

(tangentially related, Also note the misleading PS2 output in:

$ cat <(
cmdsubst>

)

(expected procsubst> / prcsubst>...)
-- 
Stephane