> FYI... yes: repositories will be a URL. For local operation, we could also
> use a path or a file: URL:
That seemed like an obvious choice. One I made for another
> file://path/repos -- use libsvn_ra_local(*)
> (*) I'm not sure whether it is //path or ///path ... *shrug* we should
> accept both forms as an absolute reference (no relative file URLs)
I agree. If you can understand a user's intent, it is completely
wrong to say (in effect): ``I know what you mean, but I won't give
it to you because you did not ask the way I want you to ask.''
> I will also warn you against using metacharacters as (short) option names.
Interesting problem. The ``meta character'' options are automatically
inserted. You always get --help and --more-help, period. If you
specify a program version, then --version is added, too. If you
specify RC files, then you get --save-opts and --load-opts. Now, given
that people already like to use ``-v'' to mean ``--verbose'', what
letters should I usurp for --help, --more-help, --save-opts and
--load-opts? Remember, AutoOpts selects the letter, not the user.
(Of course, if a client program chooses the same letter, then these
automatic options loose the flag character.)
> Bash is very good about metacharacters, but others aren't. I think you'll
> also have problems with -> and -< on any shell. And don't say that people
> should quote them :-)
So, all in all, I think people should quote them. :-)
The alphabet is small and the characters with special meaning
to shell is large. Perhaps, since everyone uses QWERTY keyboards
made for the US market, I could use the unshifted ``-<'' and
``->''? (For those that don't have U.S. keyboards, that would
be ``-,'' and ``-.''. We would be talking seriously obscure. ;-)
So, maybe, all in all, people should just use the long options?
--save-opts --load-opts --help --more-help
> help would simply be -h or --help.
It conflicts with the -h for humbug. :-)
Received on Sat Oct 21 14:36:11 2006