On Tue, 30 Jan 2018 17:41:45 +0000 Ralph Corderoy <ralph@inputplus.co.uk> 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.
--
Nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers