[gobolinux-devel] [gobolinux-commits] tools/Scripts/Functions OptionParser

[Hisham Muhammad]

On 11/20/06, Jonas Karlsson <jonka750 at student.liu.se> wrote:
> On Mon, 20 Nov 2006 02:54:23 +0100, Hisham Muhammad <hisham.hm at gmail.com> wrote:
>
> > On 11/19/06, Jonas Karlsson <jonka750 at student.liu.se> wrote:
> >> I've just commited my new implementation of OptionParser. The new
> >> functionallity can be found in the short log, but I thought I might give
> >> some examples to clear things up. Using Compile as an example, valid
> >> calls
> >> are:
> >>
> >> Compile -bS Foo
> >> Compile Foo --no-sign
> >> Compile -VnFooBar --version=2.3 Foo
> >> Compile -xppc Foo
> >> Compile -bGc"--no-app --without-lib" Foo
> >>
> >> For the arguments there are a new array, $Arg, to be used instead of $1,
> >> $2 in combinations with shift. $Arg[0] is the same as $0 and then the
> >> arguments are numbered in the order of appearance.
> >>
> >> Even though there's a new way of accessing arguments this commit didn't
> >> break the old one, but people should try to change the way arguments are
> >> handled in the existing scripts, using $Arg instead of $1 etc.
> >>
> >> Questions, views, objections? - Please! :)
> >
> > Ok, here go my questions, views and objections:
> >
> > * First of all, if this is in, then _all_ scripts have to be changed
> > to use $Arg. As it stands, it is advertising broken functionality, as
> > "Compile Foo --batch 2.0" does not work.
>
> Yes, but it could be done later as the old method of $1 still works. I
> didn't want to make too many changes in one commit (and hoped that
> somebody would help me in the rewriting :) )

$1 works but $2 doesn't, that's the important point.

> > * While I did tell you offlist that I thought the new option parser is
> > a great addition, I think  you should have posted this on the -devel
> > list before comitting, since it's a big change that affects all
> > scripts.
>
> Oh, I thought you meant to wait until next release was out.
> To be honest I think we are too kind with our CVS. Users that track CVS
> should know that it might break. If this breaks anything it's very easy
> for any user to revert, as it's just to either remove the comment at the
> end of Parse_Options or just change the names so that Parse_Options_Old
> becomes Parse_Options again. Anyhow, I've tested the most used scripts and
> none break to my knowledge. That's why I need larger testing.

I actually run CVS on my production box, and I believe others do too.
It's a good way to keep things stable and in check.

> > * I have restrictions wrt stacking short arguments and using them with
> > entry values. Things like "-xbla" look ambiguous.
>
> I thought of that and as it _should not_ be used by any script maintainer,
> a user could easily use it as it knows what should be there and options
> that require an argument is greedy. For example

I know it's not ambiguous, but it "looks ambiguous". I'm not keen on
adding features that "should not be used". Like I didn't like your
change about letting options be defined without a long or short
version - I forced both to be defined every time on purpose, to
promote consistency.

> > * Using `Arg 1` instead of ${Arg[1]} looks cleaner (a matter of
> > taste), more consistent with the rest of the option parser. I concede
> > it's less efficient, but they shouldn't be used a lot anyway: they're
> > meant to be assigned to variables with meaningful names instead of
> > being referred through numbers.
>
> I know that, as we discussed that, but then I thought that it may be used
> with backquotes in assignement and I don't like the idea of wrapping
> multiple backquotes.

Use $(Arg 1) in those cases, which nests nicely. Arg has also the
advantage of being read-only (you _really_ don't want scripts
assigning to the array).

-- Hisham