Re: Cloning getopt (and getopt_long) into popt?
On Dec 20, 2008, at 3:06 AM, Ralf S. Engelschall wrote: Ah, yes, as long as one can still build a POPT without these two symbols (to avoid conflicts) this would be a really nice addition for POPT. I would say: go for it as long as is an _optional_ feature! I should likely state the underlying reason as well, adding persistent configurable default option settings. Both popt/getopt_long have a means to configure options persistently. However, popt alias/exec attach to executables, while getopt_long can save option values (and presence) in a state file to be parsed. wget (and iirc gnupg) have functionality captured in ~/.foo file parse that is not easily/cleanly replicated with alias/exec. todo+= (with disabler) but it will likely be a while before I get back to studying rpmwget.c needs. 73 de Jeff smime.p7s Description: S/MIME cryptographic signature
Re: Cloning getopt (and getopt_long) into popt?
On Fri, Dec 19, 2008, Jeff Johnson wrote: > popt competes for mind share with getopt, and > particularly with GNU getopt_long, the Debian added borkedness (jmnsho). > > Should I add a getopt(3)/getopt_long(3) wrapper onto > popt to lower the barrier to converting from getopt_long(3)? > > I personally don't care a bit because I use popt instead > of getopt_long(3) all the time and everywhere. > > But the wrapper (with AutoFu disablers) is trivially arranged > if there is interest. Ah, yes, as long as one can still build a POPT without these two symbols (to avoid conflicts) this would be a really nice addition for POPT. I would say: go for it as long as is an _optional_ feature! Ralf S. Engelschall r...@engelschall.com www.engelschall.com __ POPT Library http://rpm5.org Developer Communication List popt-devel@rpm5.org
