Re: Simplifying command line parsing with Genparse

[Michael Geng]

On Thu, Jun 07, 2007 at 02:44:38PM +0200, Jim Meyering wrote:
> address@hidden (Michael Geng) wrote:
> > would it be an option to use Genparse (http://genparse.sourceforge.net/)
> > for command line parsing in the GNU Coreutils?
> >
> > I'm one of the developers of Genparse and I recently used some of the
> > well known Coreutils as an exercise for testing Genparse (see
> > http://genparse.sourceforge.net/examples.html). Using Genparse for
> > generating the command line parsing code could reduce the amount of
> > coreutils source code because the input to Genparse is a short config
> > file only. The overhead of writing the parser code would be delegated
> > to the tool then.
> >
> > The Genparse generated parsers call getopt() (or getopt_long()) exactly
> > the same way the Coreutils's command line parsers do it today. This
> > wouldn't be changed. So the code Genparse generates will be very similar
> > to the existing hand written parsers of the individual Coreutils tools.
> > But calling getopt() is only part of the work, preparing and evaluating
> > the results of getopt() also causes coding work which could be delegated
> > to Genparse. Genparse also automatically generates a help screen which
> > would no longer have to be done manually.
> 
> Hi Michael,
> 
> Genparse looks promising.
> I like the examples.  But there are almost 100 programs in the
> coreutils.  If genparse can really handle all of those use cases
> without causing any significant degradation in the tools, then
> it will be hard to object.
> 
> How does it deal with internationalization?

There is no internationalization. I looked at the Coreutils 
internationalization but I neither fully understood how it works 
nor do I have an idea right now how to internationalize Genparse's
output. internationalization appears to be a difficult thing.

> However, before I even consider it seriously, it'll need
> some improvements:

I appreciate your concerns very much. All of them are valid and valuable
input for Genparse development. At least some of them will need more
discussion however which I think is not interesting to everybody listening
to the Coreutils mailing list. For this reason I started a new thread
on the genparse-users mailing list
(http://sourceforge.net/mailarchive/forum.php?thread_name=20070607150633.GA26405%40t-online.de&forum_name=genparse-users).
Any posts to the genparse-users mailing list from anybody is welcome!
I will let you (and the coreutils-bug mailing list) know if there is any
progress on ony of the problems you listed.

>   - it must detect any and all write failures[*]
>   - packaging so that I can run ./configure && make && make check, and
>       if I don't happen to have cppunit infrastructure, gcj or something
>       similar, it should tell me about it directly, rather than causing
>       harder-to-diagnose build failures.
>   - one of the generated .c files I looked at calls strdup but doesn't
>       check for a NULL return value or (less important) attempt to avoid
>       the leak when the corresponding --backup=S option appears twice or more.
>   - not exactly essential, but highly recommended: it should work
>       with the latest autoconf and automake
> 
> 
> [*] with genparse-0.6.3, I get this:
> 
>   $ strace -o log -e write ./genparse -o /full/tmp/foo ../examples/ls.gp \
>     && echo exit status 0
>   creating /full/tmp/foo.h...done
>   creating /full/tmp/foo.c...done
>   exit status 0
>   $ tail -2 log
>   write(3, "/*******************************"..., 80) = -1 ENOSPC (No space 
> left on device)
>   write(1, "creating /full/tmp/foo.c...done\n", 32) = 32
> 
> The two files it claims to have created are both empty,
> and genparse exited successfully.
> This means genparse is not detecting write or close failures.
> 
> Note that in the example above, /full/tmp is a full file system that still
> has free inodes, so open can create new files, but writes always fail.