[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