On Thu, May 22, 2008 at 1:01 AM, Xavier <shiningxc@gmail.com> wrote:
Sebastian Nowicki wrote:
On 22/05/2008, at 7:13 AM, Xavier wrote:
Because you need to use -- to separate the getopt options from the argument, this is all in the manpage actually, I just figured that :) getopt -o abc -- $@" That is what makepkg does.
Yes, in GNU's getopt it works like that, but not in the BSD getopt. Even if "getopt -o abc -- $@" is used, you still get something like "-- abc -- -a -b -c", because it thinks that "-o abc -- $@" is what it has to process. BSD's getopt only takes the valid short options as the first parameter, and then the arguments to be processed [1].
Actually I am confused. If we want to use that compatible format, getopt abc $@, then we can't use long options anymore?
It appears so, which is very bad.
Ah I see.. As I said earlier, we were using getopts before getopt : http://projects.archlinux.org/?p=pacman.git;a=commitdiff;h=54b71f0427e87e6d5...
So it basically means we need to revert that commit for portability? The new way looks much nicer... I would like to have Aaron and Dan inputs here :P
I've been following this thread only peripherally. But my opinion is this: getopt/getopts in bash is very confusing and annoying. Useful for only shortopts, but once you introduce long options, it gets annoying. In all seriousness, it might be easier just to switch to manual parsing and eschew getopt/getopts altogether. I mean, all our options only take one arg, right? So parsing should be fairly simply, I'd think