Subject: Re: Bring parse_options to the shell

From: Pierre Habouzit <[email-masked]>
Date: Fri, 02 Nov 2007 17:09:25 +0100

On Fri, Nov 02, 2007 at 03:51:13PM +0000, Linus Torvalds wrote:
> 
> 
> On Fri, 2 Nov 2007, Pierre Habouzit wrote:
> 
> > On Fri, Nov 02, 2007 at 03:09:18PM +0000, Pierre Habouzit wrote:
> > > This is also something that itches me, so here is a proposal for a
> > > git-parseopt helper that can be used in shell scripts as an option
> > > normalizer like getopt(1) does.
> > > 
> > > I migrated the discussed git-clean.sh to use it as a proof of concept.
> > 
> >   Needless to say, this is fetchable from
> > git://git.madism.org/git.git#ph/parseopt
> 
> Hmm. Any reason why you didn't just extend on "git rev-parse"?

Because I wasn't aware of the fact it was used to massage arguments of a
function :) Though looking at the code git-rev-parse looks quite
complicated and does not works the proper way:

It show()s the arguments along the way, whereas you definitely need to
parse them first if you end up spitting out the usage. I could of course
plumb it as a new "mode" of git-rev-parse, but it sounds awkward.

> That command was written exactly to parse a command line. This is really 
> cheesy, and doesn't really work right (it splits up numbers too), but you 
> get the idea..

  I get the idea, though parse-options is not incremental at all, this
could probably be done, but would complicate the API (we would need to
allocate a state object e.g.). And parseoptions checks that options
getting an argument have one, checks that options exists and so on. It
looks like to me that it's not easy to plumb into rev-parse without
being a brand new independant mode.

  We can do that, if we don't want yet-another-git-builtin/command, but
in the spirit it'll remain a brand new "thing".

  Though I'd be glad to hear about what others think about it.

-- 
·O·  Pierre Habouzit
··O                                                [email-masked]
OOO                                                http://www.madism.org