[m-dev.] Getopt extension for discussion
philip at cs.mu.oz.au
Tue Apr 22 10:43:58 AEST 1997
> I was talking with Philip the other day, and he asked for a "maybe string"
> option type so that you can have:
> --opt "a string"
> or --no-opt
> He argued that this was better than using the empty string as a sentinel
> for the "no" case. The example application was filenames (in which case
> "" would always be a valid sentinel). Following is a diff that adds the
> requested functionality.
> Can anyone give a realistic example where "" is not a valid sentinel, where
> the maybe string option would be a real advantage?
Since it was my example, I thought I'd provide some more detail ...
The example a program that uses a startup file, where a default
startup file is provided eg. part of the installation.
could be used to specify a different startup file, and the option
could be used to say indicate that no startup file should be read.
This is quite common requirement, eg. for shells and typecheckers :-)
It's also a simple extension which doesn't affect the current use of getopt.
> +getopt__process_option(maybe_string(_), _Option, Flag, MaybeArg, _OptionOps,
> + OptionTable0, Result) :-
> + ( MaybeArg = yes(Arg) ->
> + map__set(OptionTable0, Flag, maybe_string(yes(Arg)),
> + OptionTable),
> + Result = ok(OptionTable)
> + ;
> + error("string argument expected in getopt__process_option")
> + ).
Tom, this error string should be different from the one used
for the clause for string(_).
Also, since you've made this change (and posted it before I could post
mine :-), please fix the bug where "-" appearing as an option is ignored
altogether. This should be passed through as an argument.
Fixing this will allow "-" to be treated as stdin/stdout as for diff or tar.
(Though bash treats "-" the same as "--" but we can't have everything).
More information about the developers