~skeeto/public-inbox

1

Re: What's everyone working on lately?

Details
Message ID
<20200805010228.GF1956@begriffs.com>
DKIM signature
pass
Download raw message
Chuck Jungmann wrote:
> I have been working on a library for processing GNU conforming command
> line options.  My objective is to make the code for processing the
> options easier to scan and modify. I was eventually going to post it
> to the list for feedback, but I'll ride your invitation to post a link
> to it right now:
> 
> https://github.com/cjungmann/readargs
> 
> I'm curious to know if anyone beside me would find this useful. I'd
> also welcome suggestions or comments about where I may be using bad or
> confusing practices.

I just happened to read an article [0] by Chris Wellons about his
criteria for correct argument processing. You could try his examples and
see how your library handles them.

0: https://nullprogram.com/blog/2020/08/01/

Re: What's everyone working on lately?

Chuck Jungmann
Details
Message ID
<afefadf1-5c1a-ac99-6a34-6fbdd60f2d29@cpjj.net>
In-Reply-To
<20200805010228.GF1956@begriffs.com> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
Thanks for the link. I had noticed that you had starred Chris Wellons' 
project and looked it over.  I wasn't aware of his article and I read it 
with interest.

My library handles short options alone or grouped, with or without 
spaces, long options, with or without '=', arbitrary order of options 
and non options.  With the exceptions of subcommands and optional-value 
options, my library handles arguments as Wellons and the GNU guidelines 
suggest.

I tried to made the library to be super easy to setup for basic stuff, 
but easily extensible.  I have an example source file that implements 
optional-value options and multi-value options (which could be modified 
to handle subcommands).

I wanted to build in optional-value options.  I'd like to conform to 
existing standards for this feature, but I couldn't find any commands 
that implement it.   My extension implementation evaluates the argument 
following the optional-value option to decide if it's a value or an 
option or non option.  For example, for an optional-value option -i for 
an input file, the custom handling could confirm the existence of the 
input file.  If the file exists, the argument becomes the value for the 
optional-value option, otherwise it's treated as the next non option 
argument.

One unusual feature I wrote for my own benefit is to easily display the 
values of each option so I can see the effect of the command line 
arguments.  This has increasing value for the developer and end user as 
the command line processing gets more complicated.  I usually attach 
this feature to -s / --show_args so it can be invoked multiple times in 
a set of arguments.

On 8/4/20 8:02 PM, Joe Nelson wrote:
> Chuck Jungmann wrote:
>> I have been working on a library for processing GNU conforming command
>> line options.  My objective is to make the code for processing the
>> options easier to scan and modify. I was eventually going to post it
>> to the list for feedback, but I'll ride your invitation to post a link
>> to it right now:
>>
>> https://github.com/cjungmann/readargs
>>
>> I'm curious to know if anyone beside me would find this useful. I'd
>> also welcome suggestions or comments about where I may be using bad or
>> confusing practices.
> I just happened to read an article [0] by Chris Wellons about his
> criteria for correct argument processing. You could try his examples and
> see how your library handles them.
>
> 0: https://nullprogram.com/blog/2020/08/01/
Export thread (mbox)