[EMAIL PROTECTED] (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?
However, before I even consider it seriously, it'll need
some improvements:
- 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.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
