> It's simply inconsistent in the present form. Why should only the
> source builtin have the long form of the option? No other builtins
> have the long form of options, which is inconsistent.
Some builtins do support long options, even though it seems
to not be documented. In fact, I based the long option shortener
function on bash pre-existing code. It is a generalization of
the shortener found in the builtins/type.def file.
There's a note there that the it's for handling obsolescent option
formats such as long options with a single dash instead of two:
-type -path -all
It also converts the standard GNU style long options:
--type --path --all
Also, I do realize that there's a big all caps warning
in the file saying that "THIS SHOULD REALLY GO AWAY".
I get the message, but I'm honestly not sure what
that's referring to. The obsolescent options,
the long options, the hack to handle them?
All of this stuff? Not sure.
The builtins seem to be quite consistent
in their support for --help though.
So there's at least some precedent
for long option support.
> Suppose you would submit an independent patch to introduce
> long option of builtins in Bash. Would you do that only
> for the source builtin?
No.
> If you consider the current form would be complete, you should provide
> the reason that the other builtins should not have the long form of
> the options, while only the source builtin should have a long option.
I don't understand why they don't all have long options to begin with.
Is there a reason for it?
> If one tries to give the long options to all the existing builtins,
> that should be discussed separately.
Certainly.
> I don't think those changes are allowed to slip in as a bonus
> of another change on the source builtin.
Well I'm not really trying to "slip in" anything.
That implies I'm deceptively trying to get my way.
I'm not. I just thought it would be a nice feature to have.
If it's not acceptable, I can and will remove the long options.
> I'm not sure about what Chet thinks, but I don't think those are
> really necessary, though it's a better design in general.
I'll wait for his review.
> I also have thoughts on the way how this was implemented, but I
> wouldn't discuss it for now.
Please do. If the implementation can be improved, I will do it.
I'm already preparing the v2 patchset based on the feedback I received.
Matheus
