Re: bin/57438: set -o with unknown option aborts a script

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/57438; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/57438: set -o with unknown option aborts a script
Date: Fri, 26 May 2023 05:07:37 +0700

     Date:        Thu, 25 May 2023 19:30:00 +0000 (UTC)
     From:        uwe%stderr.spb.ru@localhost
     Message-ID:  <20230525193000.ADEE71A9241%mollari.NetBSD.org@localhost>
 
   | If a script uses set -o ... with an unknown option, the script
   | immediately terminates with exit code of 2.
 
 That is what POSIX requires.
 
 XCU 2.8.1 (Consequences of Shell Errors)
 
     Certain errors shall cause the shell to write a diagnostic message
     to standard error and exit as shown in the following table:
 
            Error             Non-Interactive Interactive Shell Shell Diagnostic
                              Shell                             Message Required
 Shell language syntax error  shall exit      shall not exit    yes 
 Special built-in utility error shall exit[1]    shall not exit    no[2]
 
 [...more...]
 
 [1] The shell shall exit only if the special built-in utility is executed
     directly. If it is executed via the command utility, the shell shall
     not exit.
 
 [2] Although special built-ins are part of the shell, a diagnostic message
     written by a special built-in is not considered to be a shell diagnostic
     message, and can be redirected like any other utility.
 
 "set" is a special built-in utility (see XCU 2.15).   A bad option name
 is an error.  Running a script is a non-interactive shell.
 
 Hence "shall exit".
 
   | I suspect the problem is that set builtin reuses the same code
   | that is used to parse the actual command line options.
 
 It does, but that's irrelevant.   Further, there is no problem.
 It is doing what shells always have, and what POSIX requires.
 It isn't just set, any special built-in does the same thing.
 Try a bad "shift" command (like "shift x") or a bad option to
 "trap" (trap 'echo message' BADSIG).
 
   | Compare
   |
   | bash -c 'echo hello; set -o foobar; echo world'
   | hello
   | bash: line 1: set: foobar: invalid option name
   | world
 
 bash doesn't really believe there should be special built-in utilities,
 and mostly ignores the special rules for them, but compare:
 
 bash -o posix -c 'echo hello; set -o foobar; echo world'
 hello
 bash: line 1: set: foobar: invalid option name
 
 If you tell bash to do what posix requires, it does.   We simply do.
 But not so much because POSIX says so, rather POSIX says it because
 that's what shells do...
 
 mksh -c 'echo hello; set -o foobar; echo world'
 hello
 mksh: set: foobar: unknown option
 
 
 ksh93 -c 'echo hello; set -o foobar; echo world'
 hello
 ksh93: set: foobar: unknown option
 Usage: set [-sabefhkmnprtuvxBCGH] [-A name] [-o[option]] [arg ...]
  Help: set [ --help | --man ] 2>&1
 
 
 dash -c 'echo hello; set -o foobar; echo world'
 hello
 dash: 1: set: Illegal option -o foobar
 
 
 bosh -c 'echo hello; set -o foobar; echo world'
 hello
 bosh: foobar: bad option(s)
 
 
 Even our crappy /bin/ksh:
 
 ksh -c 'echo hello; set -o foobar; echo world'
 hello
 ksh: set: foobar: bad option
 
 
 Try them yourself.
 
 kre
 
 ps: The section numbers I quoted are those from the current (unpublished)
 draft, it is possible they aren't quite the same in the current released
 version - the titles, content and intent of this particular part has been
 unchanged essentially however, it was how it worked in the 7th edn Bourne sh.