On Thu, Jun 07, 2007 at 02:44:38PM +0200, Jim Meyering wrote: > [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?
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. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
