Nathan Hartman wrote on Fri, 31 Dec 2021 00:01 +00:00:
> On Tue, Dec 28, 2021 at 11:19 AM Daniel Sahlberg
> <daniel.l.sahlb...@gmail.com> wrote:
>>
>> Hi,
>>
>> While digging through Jira I stumbled upon the above mentioned issue.
>>
>> It seems fairly simple to add the -o bashdefault option when defining the
>> completion.
>>
>> Patch attached, anyone want to comment before I commit?
>>
>> Kind regards,
>> Daniel
>
>
> Interesting! I'm not an expert on bash completion but I tried the
> patch and I can confirm it seems to enable this functionality on my
> system.
>
> I am slightly worried, though, that "-o bashdefault" might be a
> bashism not compatible with all systems or shells.
Isn't tools/client-side/bash_completion specific to bash?
I can't speak to "all systems or shells", but I can answer for zsh. zsh
has a native svn(1) completion in [1], as well as an emulation facility
for loading bash completion functions ("bashcompinit").
Users are likely to be using the former.
Using our bash completion under zsh via bashcompinit is… well, not
inconceivable, and not impossible, but it requires manually changing
tools/client-side/bash_completion to work around a difference between
the two shells' syntaxes, and after that there are codepaths that raise
runtime errors, some of which warrant further code changes (e.g., in zsh
$status is read- only). In short, I think it's safe to assume zsh users
don't use our bash completion.
[1]
https://github.com/zsh-users/zsh/blob/master/Completion/Unix/Command/_subversion
> Since the bug
> report mentioned git and mplayer, I perused the completion scripts for
> those programs on my debian box to see what they're doing. Strangely
> the mplayer one didn't seem to have either "-o bashdefault" or "-o
> default", but it contains a lot of logic I haven't tried to grok;
> meanwhile the git one, also with a great deal of other logic I haven't
> tried to grok, seems to try using both options together "-o
> bashdefault -o default" and, if that fails, tries with just "-o
> default", like this:
>
> complete -o bashdefault -o default -o nospace -F $wrapper $1 2>/dev/null ||
> complete -o default -o nospace -F $wrapper $1
I'm just guessing, but it could be that «bashdefault» was a recent
addition to bash at the time that line was written, so the completion
tried to support older versions of bash as well. (That's always
a problem with completion functions: they depend both on the shell's
version and on the completed program's version.)
Or perhaps «bashdefault» was added to bash by a distro patch, and git's
completion tries to be portable to other vendors.
Daniel
P.S. Issue #4714 is also about bash completions.
