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

[Jonas Karlsson]

On Mon, 20 Nov 2006 14:49:26 +0100, Hisham Muhammad <hisham.hm at gmail.com>  
wrote:

> 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.
>
What do you mean by $2 doesn't? If $1 works, why not $2? Have I missed  
something?

>> > * 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.
>
Oh, I wasn't aware of that people use the CVS like that. If that's so,  
maybe releases should be made more often, to ensure that bugfixes are  
straightened out for the "stable" releases, instead of having to rely on  
CVS to have things sane?

>> > * 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.
>
What do you mean by "should not be used"? Does that mean that there should  
be no short options at all, since those should not be used by script  
maintainers?

The reason I choose to implement it has two reasons. One is that there's  
no way to come up with good short options for all long options, for  
example look at bug 39 (http://bugs.gobolinux.org/view.php?id=39). If we  
use -V for --no-verify (keeping consistant with capital letters for  
--no-options) what short option should be used for --version?
Another reason is that for one specific option (there might come more such  
options) I didn't want to have a short option available, namely for  
--use-contrib for InstallPackage. Having no short option the user has to  
use the long option and then cannot accidently use that option.

>> > * 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).
>
Didn't think of that... ( $(Arg 1) )
It's a good idea and I will change to that instead.

-- 
/Jonas

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/