parseargs vs. getopt

peter at ficc.uucp peter at ficc.uucp
Mon Jun 25 06:20:50 AEST 1990


From:  peter at ficc.uucp

In article <729 at longway.TIC.COM> From: David J. MacKenzie <djm at eng.umd.edu>
> Parseargs has a lot of problems; I looked at it and discarded it.

On the other hand, I looked at it and fixed them. Check comp.sources.misc.

> It
> might provide a superior interface to the programmer, but it doesn't
> provide the same interface to the user; that is, it doesn't conform to
> the standard Unix option syntax that most programs use (allowing
> ganging of multiple single-letter options into a single argument, for
> example).

Actually, it does do this. You shoulda looked harder. What it doesn't do
is handle variable nubers of arguments, which is one thing I fixed.

> Since getopt is an existing-practice de-facto standard, I
> see no justification for trying to push something quite different that
> hardly anyone uses as an IEEE standard.

Given the things that have already gone in to POSIX, even the almighty
base (such as fgetpos, or banning silent truncation of long file names)
I think that's a bit of a quibble. Getopt pretty much has to stay, I
agree. But parseargs should be considered as a recommended alternative.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.
<peter at ficc.ferranti.com>


Volume-Number: Volume 20, Number 49



More information about the Comp.std.unix mailing list