Path: utzoo!attcan!uunet!longway!std-unix From: peter@ficc.uucp Newsgroups: comp.std.unix Subject: Re: parseargs vs. getopt Message-ID: <737@longway.TIC.COM> Date: 24 Jun 90 20:20:50 GMT References: <378@usenix.ORG> <728@longway.TIC.COM> <729@longway.TIC.COM> Sender: std-unix@longway.TIC.COM Reply-To: peter@ficc.ferranti.com (Peter da Silva) Organization: Xenix Support, FICC Lines: 32 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: peter@ficc.uucp In article <729@longway.TIC.COM> From: David J. MacKenzie > 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. Volume-Number: Volume 20, Number 49