[m-users.] getopt; checking for invalid/illegal option values
Sean Charles (emacstheviking)
objitsu at gmail.com
Mon May 3 05:59:30 AEST 2021
Thanks Zoltan.
What is the purpose of a special handler ?
I will implement a ‘post-processing’ step as you suggest, to sanity check them options as given. This would be required as I also read from a confiuration file with command line options ultimately taking precedence.
Thank you.
Sean.
> On 2 May 2021, at 20:57, Zoltan Somogyi <zoltan.somogyi at runbox.com> wrote:
>
>
>
> On Sun, 2 May 2021 20:47:29 +0100, "Sean Charles (emacstheviking)" <objitsu at gmail.com> wrote:
>> I have a working getopt configuration and, to cut a long story short, is it possible to restrict the values that an option can take or not ?
>
> You can restrict the type, using the option's entry in the option_defaults predicate.
> There is no way to disallow any values in that type.
>
>> Essentially I don’t want to the application to start of the command line contains junk.
>
> The standard way to achieve this is to postprocess the option table returned
> by getopt. This can e.g. check whether a string option has one of a set of permitted
> values (possibly after smashing case), generating an error if not, and recording
> the result in an enum that is stored *separately from the option table*, maybe
> in the globals structure. It can also do other checks that affect more than one
> option, e.g. generating an error if the users sets both a "verbose" option
> and a "quiet" option.
>
> Basically, the getopt module has no mechanism built into it for such semantic
> checks, because the space of possible semantic checks one may want
> is so large.
>
> Zoltan.
>
>
More information about the users
mailing list