[Bash-completion-devel] A question about 9af6f3504e8c94e5ead187b7cd223bd481548957

[Ville Skyttä]

On 04/18/2011 01:28 AM, Igor Murzov wrote:
> Hi, list.
> 
> Can someone throw a light on why changing
>   have && { ... }
> to
>   have || return  { ... }
> is a good idea?

The commit message of the revision in $Subject explains it.

> It is not clear how to return from script with multiple
> functions. For example in completions/xz I see following:
> ---------------------------------------------
> have xz || have pxz || return
> 
> _xz()
> {
>   ...
> } && complete -F _xz xz pxz
> 
> have xzdec &&
> _xzdec()
> {
>  ...
> } && complete -F _xzdec xzdec
> ---------------------------------------------
> If there is no xz in the system, but xzdec is there, then both functions will 
> not be loaded.

That's right, fixed in git.  This kind of early return was not supposed
to be applied in that file just like it isn't applied in for example
completions/shadow, because just as you said, it's not clear how to do
it; the approach I intended to take was "don't, at least for now".

Personally my first general thought about this is that it'd be better if
the number of files that define multiple completions would be as low as
possible, but then again we're now moving towards dropping bash < 4.1
support in the next major version and it may enable us to do things in a
way that wasn't possible or practical before, and may also make these
issues (trying to optimize load time the way it was done before) more or
less moot, so I wouldn't spend much time thinking about this stuff the
moment.

> May be the better way is to place all names to the first check 
> and left everything else unchanged like this:
> ---------------------------------------------
> have xz || have pxz || have xzdec || return
> 
> have xz || have pxz && _xz()
> {
>   ...
> } && complete -F _xz xz pxz
> 
> have xzdec &&
> _xzdec()
> {
>  ...
> } && complete -F _xzdec xzdec
> ---------------------------------------------
> This way I think it will be more correct and still fast if no appropriate 
> utilites found. But this way to my mind it's somewhat hard to maintain all 
> these scripts.

I agree it's not very maintainable and I think it's actually ugly, and I
believe it will also cause significant load time slowdowns - but just
for the ugliness/maintenance point of view it's something I wouldn't
want to see.  See recent discussion on this list for more information.
Each successful call to have() sets have=yes which can be used instead
of calling the same have() again, but unfortunately that doesn't help
when working simultaneously/interleaved with several different
utilities' have()'s.