From owner-freebsd-hackers@FreeBSD.ORG Tue Sep 28 18:49:08 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id 7B31D1065679; Tue, 28 Sep 2010 18:49:08 +0000 (UTC) Date: Tue, 28 Sep 2010 18:49:08 +0000 From: Alexander Best To: perryh@pluto.rain.com Message-ID: <20100928184908.GA99059@freebsd.org> References: <20100927012936.GA32352@freebsd.org> <4ca026de.pOkFIzh1Wymrvuow%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4ca026de.pOkFIzh1Wymrvuow%perryh@pluto.rain.com> Cc: freebsd-hackers@freebsd.org Subject: Re: adding a new lib for more advanced argument parsing X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 18:49:08 -0000 On Sun Sep 26 10, perryh@pluto.rain.com wrote: > Alexander Best wrote: > > > ... getopt(3) is clearly not suitable for handling such complex > > options. camcontrol.c even contains a whole paragraph about why > > getopt(3) is considered not appropriate to handle camcontrol's > > argument parsing requirements ... > > > why not do a vendor import of popt 1.16 e.g.? are there license > > restrictions? > > AFAIK it is GPL; it was used in Red Hat Linux prior to the split > into Fedora and RHEL (and may still be, for all I know). > > > or maybe some other lib... > > Dunno what-all may be available. > > popt has its own set of limitations. Check the archives from > the RPM mailing list from around the time when RPM switched > to popt, or perhaps it was when rpmbuild was split out into > a separate executable, for the laundry list of issues they > encountered in attempting to maintain compatibility at the > command line level between what they had before and after. oh i didn't know that. i thought it was superior to getopt() in every fashion. also i'm not voting to completely get rid of getopt(), but merely to make it easier for developers to handle complex options. i mean posix is fine and all, but if they recommend using horses instead of cars shouldn't it be decided that we need both: for comptaibility and performance? cheers. alex -- a13x