[Help-bash] 'bash -n' without a script argument not ignored by interactive shell

[Alan D. Salewski]

Hi Folks,

A friend stumbled over this surprising (to me) behavior the other day in
which an invocation of:

    $ bash -n

dropped him into an interactive shell in which no commands appeared to
work. It was surprising (and somewhat comical) because the intention was
not to create an interactive subshell at all, but rather to check the
syntax on a script via what turned out to be a too-hastily-typed version
of the intended command:

    $ bash -n path/to/somescript

The appearance, however, was that the command I was directing him to
type had hosed his (remote) shell session.

As entertaining as this might be[0], the description in bash(1) makes me
think that this is unintended behavior:

<quote>
    OPTIONS
        All of the single-character shell options documented in the description
        of the set builtin command can be used as options  when  the  shell  is
        invoked.
    ...
            set [--abefhkmnptuvxBCEHPT] [-o option-name] [arg ...]
            set [+abefhkmnptuvxBCEHPT] [+o option-name] [arg ...]
    ...
                -n     Read commands but do not execute them.  This may be used
                       to  check  a  shell  script  for syntax errors.  This is
                       ignored by interactive shells.

                -o option-name
    ...
                       noexec  Same as -n.
</quote>

Consistent with the documentation, the following commands show the option
being ignored once you are already in an interactive shell:

    $ set -n
    <commands still work here>

    $ set -o noexec
    <commands still work here>

Is it a bug that 'bash -n' without a file name argument creates an
interactive[1] shell with the noexec feature enabled?

Thanks,
-Al


[0] I intend to use this as a prank on the next five people at the office
    who walk away from their machines without locking their screens  :-)

    If your colleagues do this to you, rest assured that you can CTRL-d
    your way out of it, even though 'exit' won't work. Do be a good sport,
    though, and make a good show of being flummoxed before breaking out of
    it and then flipping them the bird.


[1] I was going to describe the noexec interactive subshell as "useless",
    but while researching it I found evidence of somebody relying on that
    behavior (to create a sort of ad hoc write(1)):

        https://ubuntuforums.org/archive/index.php/t-2089367.html