Re: [Nmh-workers] switches and smatch

[Bakul Shah]

On Tue, 30 Jan 2018 17:41:45 +0000 Ralph Corderoy <address@hidden> wrote:
Ralph Corderoy writes:
> 
> Separate to completion, there's the issue of a non-nmh program being
> able to accept all of an nmh's program's options and add some of its
> own, hopefully without clashing.  Whether an nmh option takes an
> argument or not is the issue?  That could be obtained from a new option
> to every command, or it could be built and installed as a defined-format
> data file.
>
> Ideally something simple to use from a Bourne-shell script, e.g. a
> look-up with keys `scan' and `-for' would fail, `scan' and `-forma'
> would indicate one further word needed, meaning `format-string'.  This
> would probably mean having the possible expansions, e.g. `-forma' and
> `-format', present so the script isn't doing the labour.

Something like getopt(1) can be useful:

        args=`mh-getopt -file: -folder: -nosilent -version -- $*`
        if [ $? -ne 0 ]; then echo 'Usage: ...'; exit 1; fi
        while :; do
            case "$1" in
            -file) shift; file=$2; shift;;
            -folder) shift; folder=$2; shift;;
            -silent) shift; silent=$2; shift;;
            -*) echo Ambiguous option: $1; exit 1;;
            --) shift; break;;
            esac
        done

In the specification options that take an arg end in :.
Options that can be negated start with -no.
Actual args are separated with --.

The idea is that the output expands unique abbreviated options
and turns binary options into boolean options (e.g -s will map
to -silent yes, -nos will map to -silent no, -fi to -file, -fo
to -folder etc.). Ambiguous options are left alone.

I wrote some go code for parsing mh style options using go's
for use within go programs.  Perhaps it can be used to build
such a program.

> I'm not convinced of a need, but I expect there's others out there that
> have fought nmh over this.

Ditto.