CVS commit: [netbsd-9] src/bin/sh

["Martin Husemann" <martin%netbsd.org@localhost>]

Module Name:    src
Committed By:   martin
Date:           Wed Oct  1 15:27:36 UTC 2025

Modified Files:
        src/bin/sh [netbsd-9]: mkoptions.sh option.list

Log Message:
Pull up following revision(s) (requested by kre in ticket #1970):

        bin/sh/option.list: revision 1.12
        bin/sh/mkoptions.sh: revision 1.6
        bin/sh/mkoptions.sh: revision 1.7
        bin/sh/mkoptions.sh: revision 1.8
        bin/sh/mkoptions.sh: revision 1.9

>From Jan-Benedict Glaw:
Fix a redirection and prepare a stable sort for upper-/lowercase
option letters

This script is a mess, I strongly believe that it should be rewritten.
However, I'm not 100% sure why it was invented in the first place
(come on, the generated header file isn't _that_ complicated that
it couldn't be sanely managed by hand!), but let's fix the sorting
order by using LC_ALL=C.

Also add a few 'X' to the `mktemp` template to make non-BSD
implementations happy. As a bonus, actually *use* the initial `sed`
output instead of throwing it away by piping it into `sort` with
also connecting `sort`'s stdin with the original input file...

Redo the mktemp(1) part - some mktemp's (including ours) require the
XXXX's to be at the end of the name (like mk*temp(3)) so however well
it will work with mktemp implementations which allow the X's to be
anywhere in the final component of the name, it will work just as
well on them with the X's at the end.

But we don't normally need all of that mess - knowing which temp
file is which is useful only when debugging the script, and that's
(mostly) long done.   So, in normal uses now just use $(mktemp) and
allow mktemp to pick its own name - we don't need to know what it is.
Every mktemp(1) supports that mode of operation.
Bug when debugging the script (which for current purposes will be
taken to be when the -x flag is passed to the shell running it, to
trace what it does) then we will make the temp files have names we
can recognise (and in that case, also don't delete them when done).

While here, check for mktemp(1) failing, and abort if that
happens (we assume that if it fails it will write an error
message to stderr, so the script does not need to.)

As for the purpose of the script ... of course the header file
generated (or an equivalent elsewhere) could be generated and
maintained by hand, but why would anyone want to do all that
work when software can do it for us, and do it correctly without
human thought?

This also allows the options in the master list (option.list) to be
arranged in a way that is meaningful for them, unrelated to the order
the shell needs to have them in (or rearrange them to be at run time)
and have that order shuffled however is convenient.   Currently all
the posix standard options are first, then the "hybrid" options, and
finally the local ones for this shell.   Currently "pipefail" is in the
final set, but once the next posix version is published, that will
become a standard option, and get moved in the list - the shell won't
even notice as this script puts the options into shell desired order.

Be more explicit with sort fields to produce consistent results with gnu
sort (Jan-Benedict Glaw)

Allow '+' to be specified as the "one char option name" for long options
that don't have a 1 char equivalent, but do want to become a member of
an option set.  The '+' is otherwise ignored.   This is similar to '-'
in that position, except that skips past the option set field, and is
followed directly by the default value, '+' does not do that.
This currently changes nothing, as there are no current options that
use it (or would want to).

PR bin/59646 option.list wsp consistency
Be consistent with use of tab/space in fields used as
sort keys, so versions of sort which might not behave
exactly as we expect should still produce the same results.


To generate a diff of this commit:
cvs rdiff -u -r1.5 -r1.5.6.1 src/bin/sh/mkoptions.sh
cvs rdiff -u -r1.9 -r1.9.2.1 src/bin/sh/option.list

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.