On Wed, Sep 16, 2009 at 6:08 PM, Allan McRae <allan@archlinux.org> wrote:
Dieter Plaetinck wrote:
On Wed, 16 Sep 2009 13:40:37 -0500 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Wed, Sep 16, 2009 at 12:12 PM, Xavier <shiningxc@gmail.com> wrote:
On Wed, Sep 16, 2009 at 6:39 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
> > Thanks for pointing that out. > I only did a quick look at the outputs of a recursive grep for getopt > but > missed that it only found it in some comments... >
As makepkg shebangs for /bin/bash, why don't we use the getopts buildin of bash in the first place, was there a reason to not use it?
To make usage of it could be a reduction in code size (will look into it if it's desired) and also would not be a portability issue IMO.
It's not portable
a bash builtin should be the most portable thing :)
Doh, I skipped over the "builtin" part :S
We used getopts in the beginning, but it was changed to gnu getopt (probably because supporting both long and short options is much easier), and then we had to move to our own implementation for portability problem.
This is what I meant
My 2 cents: portability is important, and code conciseness is more important then having a fancy interface with many possibilities. Isn't it just redundant/bloat to support both long and short ones?
No.... there are only so many letters of the alphabet and we still have many long options without letters assigned to them that have no obvious shortening.
No, if anything I'd drop short options and keep long, but there would be a lot of pushback. Does it matter if it works, and several people here can understand it well enough? Most people didn't even know we did this until today and we surely didn't hear objections when it went in, so it clearly isn't that bad... -Dan