[PATCH v3 0/1] completion: dynamic completion loading
In this small patch I want to introduce a way to dynamically load completion scripts for external subcommands. A few years ago, you would put a completion script (which defines a Bash function _git_foo for a custom git subcommand foo) into /etc/bash_completion.d, or save it somewhere in your $HOME and source it manually in your .bashrc. Starting with bash-completion v2.0 (or, to be absolutely exact, the preview versions started at v1.90), completion scripts are not sourced at bash startup anymore. Rather, when typing in a command and trigger completion by pressing the TAB key, the new bash-completion's main script looks for a script with the same name as the typed command in the completion directory, sources it, and provides the completions defined in this script. However, that only works for top level commands. After a completion script has been found, the logic is delegated to this script. This means, that the completion of subcommands must be handled by the corresponding completion script. As it is now, git is perfectly able to call custom completion functions, iff they are already defined when calling the git completion. With my patch, git uses an already defined loader function of bash-completion (or continues silently if this function is not found), loads an external completion script, and provides its completions. An example for an external completion script would be /usr/share/bash-completion/completions/git-foo for a git subcommand foo. Changes since v2: - Replaced __load_completion with _completion_loader, which was introduced way before the former and should therefor be available even in older distributions - Updated commit message with explanations from Szeder Gábor Changes since v1 (RFC): - Re-arranged if-fi statement to increase readability (suggested by Junio C Hamano) - Re-worded commit message to include the exakt version of bashcomp that introduced dynamic loading (suggested by Stefan Beller) Florian Gamböck (1): completion: load completion file for external subcommand contrib/completion/git-completion.bash | 10 ++ 1 file changed, 10 insertions(+) -- 2.16.1
[PATCH v3 1/1] completion: load completion file for external subcommand
Adding external subcommands to Git is as easy as to put an executable
file git-foo into PATH. Packaging such subcommands for a Linux
distribution can be achieved by unpacking the executable into /usr/bin
of the user's system. Adding system-wide completion scripts for new
subcommands, however, can be a bit tricky.
Since bash-completion started to use dynamical loading of completion
scripts since v1.90 (preview of v2.0), it is no longer sufficient to
drop a completion script of a subcommand into the standard completions
path, /usr/share/bash-completion/completions, since this script will not
be loaded if called as a git subcommand.
For example, look at https://bugs.gentoo.org/544722. To give a short
summary: The popular git-flow subcommand provides a completion script,
which gets installed as /usr/share/bash-completion/completions/git-flow.
If you now type into a Bash shell:
git flow
You will not get any completions, because bash-completion only loads
completions for git and git has no idea that git-flow is defined in
another file. You have to load this script manually or trigger the
dynamic loader with:
git-flow # Please notice the dash instead of whitespace
This will not complete anything either, because it only defines a Bash
function, without generating completions. But now the correct completion
script has been loaded and the first command can use the completions.
So, the goal is now to teach the git completion script to consider the
possibility of external completion scripts for subcommands, but of
course without breaking current workflows.
I think the easiest method is to use a function that was defined by
bash-completion v1.90, namely _completion_loader. It will take care of
loading the correct script if present. Afterwards, the git completion
script behaves as usual.
_completion_loader was introduced in commit 20c05b43 of bash-completion
(https://github.com/scop/bash-completion.git) back in 2011, so it should
be available in even older LTS distributions. This function searches for
external completion scripts not only in the default path
/usr/share/bash-completion/completions, but also in the user's home
directory via $XDG_DATA_HOME and in a user specified directory via
$BASH_COMPLETION_USER_DIR.
The only "drawback" (if it even can be called as such) is, that if
_completion_loader does not find a completion script, it automatically
registers a minimal function for basic path completion. In practice,
however, this will not matter, because in this case the given command is
a git command in its dashed form, e.g. 'git-diff-index', and those have
been deprecated for a long time.
This way we can leverage bash-completion's dynamic loading for git
subcommands and make it easier for developers to distribute custom
completion scripts.
Signed-off-by: Florian Gamböck <m...@floga.de>
---
contrib/completion/git-completion.bash | 10 ++
1 file changed, 10 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index b09c8a236..604ba2b03 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -3096,12 +3096,22 @@ __git_main ()
fi
local completion_func="_git_${command//-/_}"
+ if ! declare -f $completion_func >/dev/null 2>/dev/null &&
+ declare -f _completion_loader >/dev/null 2>/dev/null
+ then
+ _completion_loader "git-$command"
+ fi
declare -f $completion_func >/dev/null 2>/dev/null && $completion_func
&& return
local expansion=$(__git_aliased_command "$command")
if [ -n "$expansion" ]; then
words[1]=$expansion
completion_func="_git_${expansion//-/_}"
+ if ! declare -f $completion_func >/dev/null 2>/dev/null &&
+ declare -f _completion_loader >/dev/null 2>/dev/null
+ then
+ _completion_loader "git-$expansion"
+ fi
declare -f $completion_func >/dev/null 2>/dev/null &&
$completion_func
fi
}
--
2.16.1
Re: [PATCH v2 1/1] completion: load completion file for external subcommand
On 2018-04-29 15:08, SZEDER Gábor wrote: On Sun, Apr 29, 2018 at 1:15 PM, Florian Gamböck <m...@floga.de> wrote: I sense a problem here. If I have a directory with a file xyzfoobar in it, and I type `git xyz`, with no defined subcommand that starts with these letters, then minimal bashcomp would give me `git xyzfoobar`, which can of course not execute. This can be unintuitive for users, as in: "If it can't be executed correctly, then why does it even suggest such a completion?" I'm not sure I understand the problem. After 'git xyz' (note there is no space between 'xyz' and ) we try to complete the name of a git command, not options of a git command. This means: - At this point we don't look for a _git_xyz() function, so we'll return from __git_main() before even reaching the piece of code your patch modifies. - There are (presumably) no commands starting with 'xyz', so we don't list any commands. Bash will then fall back to its own filename completion, and that's where that 'xyzfoobar' will come from. It has been behaving like this basically since forever. And after 'git xyz ' (this time with space) we already complete the next word, not 'xyz'. You are absolutely right! I don't know what my brain was making up here, I am sorry. The minimal completion will come up regardless if no valid completion can be found. I think I mixed up the meaning of $cword in __git_main. It is correct, if I want to complete `git xyz`, then my patch is never reached. I think all you need to do is run a s/__load_completion/_completion_loader/ on your patch and update the commit message with relevant bits from the above discussion. I can do that, no problem. But prior to that I want to be sure that you are okay with the above mentioned drawback. Will the behavior be acceptable in this case? Or should we try to somehow "undo" the minimal completion afterwards? As explained above, I don't think there is any drawback here. Or at least not any new drawback that your patch is introducing. Or I'm completely missing your point; certainly a possibility, it's early Sunday afternoon, after all :) Okay, then I'll prepare the next round. Thank you very much for your helpful feedback!
Re: [PATCH v2 1/1] completion: load completion file for external subcommand
On 2018-04-25 16:40, SZEDER Gábor wrote: In my previous emails I overlooked the _completion_loader() helper function. It seems that this function does almost exactly what we want. It was introduced along with dynamic completion loading back in 20c05b43, so it's available for us even in older LTS/Enterprise releases. Since cad3abfc it's a wrapper around __load_completion() and thus benefits from all the improvements, notably searching for completion scripts in a user-specified directory ($BASH_COMPLETION_USER_DIR) or in the user's home directory ($XDG_DATA_HOME or ~/.local/...) as well. It loads the matching completion script, but does not call the completion function unconditionally. Sounds good so far. The "almost" refers to he case when _completion_loader() can't find a completion script with a matching name to load, and then registers the _minimal() completion function for the given command to do basic path completion as fallback. I don't think this matters in practice, because in this case the given command is a git command in its dashed form, e.g. 'git-diff-index', and those have been deprecated for a long time. I sense a problem here. If I have a directory with a file xyzfoobar in it, and I type `git xyz`, with no defined subcommand that starts with these letters, then minimal bashcomp would give me `git xyzfoobar`, which can of course not execute. This can be unintuitive for users, as in: "If it can't be executed correctly, then why does it even suggest such a completion?" I think all you need to do is run a s/__load_completion/_completion_loader/ on your patch and update the commit message with relevant bits from the above discussion. I can do that, no problem. But prior to that I want to be sure that you are okay with the above mentioned drawback. Will the behavior be acceptable in this case? Or should we try to somehow "undo" the minimal completion afterwards?
Re: [PATCH v2 1/1] completion: load completion file for external subcommand
On 2018-04-23 17:12, SZEDER Gábor wrote:
On Thu, Apr 19, 2018 at 9:07 PM, Florian Gamböck <m...@floga.de>
wrote:
On 2018-04-18 21:51, SZEDER Gábor wrote:
Would it be possible to use _xfunc() instead to plug that hole? It
seems the be tricky, because that function not only sources but also
_calls_ the completion function.
But isn't this exactly what we want?
No, that's definitely not what we want.
The bash-completion project can get away with it, because they only
use their _xfunc() to source a file they themselves ship and to call a
completion function they know that that file contains.
We, however, would like to load a file that might not exist and to
call a function that might not be defined. Git has a lot of plumbing
commands with neither a corresponding _git_plumbing_cmd() completion
function in our completion script nor a corresponding
'git-plumbing-cmd' file that could be sourced dynamically to provide
that function. The same applies to any 'git-foo' command in the
user's $PATH (the user's own scripts or various git-related tools,
e.g. Git LFS).
So if someone tries e.g. 'git diff-index ' to complete files in
the current directory, then it would result in an error message like
_git_diff_index: command not found
Furthermore, earlier versions of _xfunc(), I think until the
introduction of __load_completion(), tried to source the file given
as parameter without checking its existence beforehand, so on whatever
LTS I happen to be currently using I would also get an error like
bash: /usr/share/bash-completion/completions/git-diff-index: No such
file or directory
Finally, since all this is running in the user's interactive shell,
Bash will even run the 'command_not_found_handle', if it's set (and
most Linux distros do set it in their default configuration (OK, maybe
not most, but at least some of the more popular do)), which may or may
not have any suggestions, but at the very least it takes quite a while
to scan through its database.
You're right, this could be a problem.
Then how about the following patch? This is one of my very first
iterations of this patch, before even sending it to the mailing list.
Actually this is similar to what the original _xfunc did, plus existence
checking and minus premature function calling. In the directory of the
git completion script, if there is an appropriate script for the current
subcommand, if it is a regular file (or a valid symlink) and if it is
readable, then source it and test the existence of the completion
function again. Likewise for a possible alias.
-- >8 --
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2615,10 +2615,21 @@ __git_main ()
local completion_func="_git_${command//-/_}"
declare -f $completion_func >/dev/null && $completion_func && return
+ local completion_dir="$(dirname ${BASH_SOURCE[0]})"
+ local completion_file="$completion_dir/git-$command"
+ [ -f "$completion_file" -a -r "$completion_file" ] && .
"$completion_file"
+ declare -f $completion_func >/dev/null && $completion_func && return
+
local expansion=$(__git_aliased_command "$command")
if [ -n "$expansion" ]; then
words[1]=$expansion
+
completion_func="_git_${expansion//-/_}"
+ declare -f $completion_func >/dev/null && $completion_func &&
return
+
+ completion_file="$completion_dir/git-$expansion"
+ [ -f "$completion_file" -a -r "$completion_file" ] &&
+ . "$completion_file"
declare -f $completion_func >/dev/null && $completion_func
fi
}
Re: [PATCH v2 1/1] completion: load completion file for external subcommand
On 2018-04-18 21:51, SZEDER Gábor wrote:
On Tue, Apr 10, 2018 at 10:28 PM, Florian Gamböck <m...@floga.de>
wrote:
Adding external subcommands to Git is as easy as to put an executable
file git-foo into PATH. Packaging such subcommands for a Linux
distribution can be achieved by unpacking the executable into
/usr/bin of the user's system. Adding system-wide completion scripts
for new subcommands, however, can be a bit tricky.
Since bash-completion started to use dynamical loading of completion
scripts since v1.90 (preview of v2.0),
I believe the main bash-completion repository can be found at:
https://github.com/scop/bash-completion.git
This repository still contains the branch 'dynamic-loading'; for the
record it points to 3b029892f6f9db3b7210a7f66d636be3e5ec5fa2.
Two commits on that branch are worth mentioning:
20c05b43 (Load completions in separate files dynamically, get rid of
have()., 2011-10-12)
5baebf81 (Add _xfunc for loading and calling functions on demand,
use it in apt-get, cvsps, rsync, and sshfs., 2011-10-13)
Nice, thanks for the pointers!
(...)
I think the easiest method is to use a function that is defined by
bash-completion v2.0+, namely __load_completion.
This is wrong, __load_completion() was introduced in cad3abfc
(__load_completion: New function, use in _completion_loader and
_xfunc, 2015-07-15), and the first release tag containg it is '2.2'
from 2016-03-03.
Dang, I thought it was introduced at the same time. Sorry for that. I
guess, 2016 is a bit too young to take it for granted then?
The release tags '1.90' and '2.0' are from 2011-11-03 and 2012-06-17,
respectively. This leaves a couple of years long hole where
completions were already loaded dynamically but there was no
__load_completion() function.
Would it be possible to use _xfunc() instead to plug that hole? It
seems the be tricky, because that function not only sources but also
_calls_ the completion function.
But isn't this exactly what we want? Lucky us, we can replace the whole
if-fi block with a simpler:
_xfunc git-$command $completion_func 2>/dev/null && return
If _xfunc is not defined -- as in, bashcomp is not installed / loaded --
then the return will not get called and the original completion will
continue:
declare -f $completion_func >/dev/null 2>/dev/null &&
$completion_func && return
Since this would be redundant, we could define a fall-back for _xfunc
like so:
declare -f _xfunc || _xfunc() {
declare -f $completion_func >/dev/null 2>/dev/null &&
$completion_func && return
}
This way, we retain the "old" behavior and get dynamic loading if
bashcomp is available. The actual call to get the completions would just
be _xfunc like in my first example above.
What do you think?
--
Regards
Florian
[PATCH v2 1/1] completion: load completion file for external subcommand
Adding external subcommands to Git is as easy as to put an executable
file git-foo into PATH. Packaging such subcommands for a Linux
distribution can be achieved by unpacking the executable into /usr/bin
of the user's system. Adding system-wide completion scripts for new
subcommands, however, can be a bit tricky.
Since bash-completion started to use dynamical loading of completion
scripts since v1.90 (preview of v2.0), it is no longer sufficient to
drop a completion script of a subcommand into the standard completions
path, /usr/share/bash-completion/completions, since this script will not
be loaded if called as a git subcommand.
For example, look at https://bugs.gentoo.org/544722. To give a short
summary: The popular git-flow subcommand provides a completion script,
which gets installed as /usr/share/bash-completion/completions/git-flow.
If you now type into a Bash shell:
git flow
You will not get any completions, because bash-completion only loads
completions for git and git has no idea that git-flow is defined in
another file. You have to load this script manually or trigger the
dynamic loader with:
git-flow # Please notice the dash instead of whitespace
This will not complete anything either, because it only defines a Bash
function, without generating completions. But now the correct completion
script has been loaded and the first command can use the completions.
So, the goal is now to teach the git completion script to consider the
possibility of external completion scripts for subcommands, but of
course without breaking current workflows.
I think the easiest method is to use a function that is defined by
bash-completion v2.0+, namely __load_completion. It will take care of
loading the correct script if present. Afterwards, the git completion
script behaves as usual.
This way we can leverage bash-completion's dynamic loading for git
subcommands and make it easier for developers to distribute custom
completion scripts.
Signed-off-by: Florian Gamböck <m...@floga.de>
---
contrib/completion/git-completion.bash | 10 ++
1 file changed, 10 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index b09c8a236..09a820990 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -3096,12 +3096,22 @@ __git_main ()
fi
local completion_func="_git_${command//-/_}"
+ if ! declare -f $completion_func >/dev/null 2>/dev/null &&
+ declare -f __load_completion >/dev/null 2>/dev/null
+ then
+ __load_completion "git-$command"
+ fi
declare -f $completion_func >/dev/null 2>/dev/null && $completion_func
&& return
local expansion=$(__git_aliased_command "$command")
if [ -n "$expansion" ]; then
words[1]=$expansion
completion_func="_git_${expansion//-/_}"
+ if ! declare -f $completion_func >/dev/null 2>/dev/null &&
+ declare -f __load_completion >/dev/null 2>/dev/null
+ then
+ __load_completion "git-$expansion"
+ fi
declare -f $completion_func >/dev/null 2>/dev/null &&
$completion_func
fi
}
--
2.16.1
[PATCH v2 0/1] completion: dynamic completion loading
In this small patch I want to introduce a way to dynamically load completion scripts for external subcommands. A few years ago, you would put a completion script (which defines a Bash function _git_foo for a custom git subcommand foo) into /etc/bash_completion.d, or save it somewhere in your $HOME and source it manually in your .bashrc. Starting with bash-completion v2.0 (or, to be absolutely exact, the preview versions started at v1.90), completion scripts are not sourced at bash startup anymore. Rather, when typing in a command and trigger completion by pressing the TAB key, the new bash-completion's main script looks for a script with the same name as the typed command in the completion directory, sources it, and provides the completions defined in this script. However, that only works for top level commands. After a completion script has been found, the logic is delegated to this script. This means, that the completion of subcommands must be handled by the corresponding completion script. As it is now, git is perfectly able to call custom completion functions, iff they are already defined when calling the git completion. With my patch, git uses an already defined loader function of bash-completion (or continues silently if this function is not found), loads an external completion script, and provides its completions. An example for an external completion script would be /usr/share/bash-completion/completions/git-foo for a git subcommand foo. Changes since v1 (RFC): - Re-arranged if-fi statement to increase readability (suggested by Junio C Hamano) - Re-worded commit message to include the exakt version of bashcomp that introduced dynamic loading (suggested by Stefan Beller) Florian Gamböck (1): completion: load completion file for external subcommand contrib/completion/git-completion.bash | 10 ++ 1 file changed, 10 insertions(+) -- 2.16.1
Re: [RFC PATCH 1/1] completion: load completion file for external subcommand
On 2018-04-10 07:06, Junio C Hamano wrote: Florian Gamböck <m...@floga.de> writes: Does my reasoning make sense? Not at all. :-( That actually hurt a bit. But ... I mean, the result will be exactly the same, we are clearly only talking about readability here. ... I agree, and I also think the "readability" is not absolute anyway. FWIW, personally I'd find "if $completion_func does not yet exist and a way to dynload stuff exists, then use that way to load it from an external file" the most natural way to express what you are doing. Then let's go with that. Maybe I am overthinking things here and re-wording doesn't hurt. I'll send a new patch version later this day, including the commit message re-wording suggestion from Stefan. Thank you for your feedback! -- Regards Florian
Re: [RFC PATCH 1/1] completion: Load completion file for external subcommand
On 2018-04-09 11:26, Stefan Beller wrote: Since bash-completion started to use dynamical loading of completion scripts somewhere around v2.0, it is no longer sufficient to drop a completion script of a subcommand into the standard completions path, /usr/share/bash-completion/completions, since this script will not be loaded if called as a git subcommand. Also v1.90 here? (hint from the cover letter, please be exact) Yes, it started at 1.90. I will reword the commit message and be more exact in the next iteration. If Gits own completion script would be broken up by subcommand, would that also deliver an improvement in performance? As it is now, the completion script is quite big. On a system with limited resources, the initial loading time can be long and the memory footprint is big, given that most users will just use a few commands. If you just use the "commit" subcommand, the first loading of the two (smaller) scripts will be slightly longer the first time (but not as long as with one big script, I think), but the footprint will be drastically lower. The whole script is 56kB big (without comments), after radically removing everything which is not connected to _git_commit, it is only 11kB. So to answer your question: Yes. My first intuition is, that by splitting the completion script and loading the sub-scripts dynamically, it will improve in terms of speed and overall memory footprint, at least for the average user that does not fire up all possible git commands. -- Regards Florian
Re: [RFC PATCH 1/1] completion: load completion file for external subcommand
On 2018-04-09 18:36, Junio C Hamano wrote:
Florian Gamböck <m...@floga.de> writes:
> Good point. I could go even further and ditch the if-construct:
>
>! declare -f $completion_func && declare -f __load_completion &&
>__load_completion "git-$command"
I personally find that a lot harder to read than if/then/fi.
Then I mis-understood you the first time. It sounded a bit as if you
wanted to avoid if-fi. After all, the rest of this code block also uses
quite long &&-chains.
Then we are back at the first question:
>local completion_func="_git_${command//-/_}"
> + if ! declare -f $completion_func >/dev/null 2>/dev/null; then
> + declare -f __load_completion >/dev/null 2>/dev/null &&
> + __load_completion "git-$command"
wouldn't the above be easier to read if it were
if ! declare ... $completion_func ... && declare -f __load_completion
then
__load_completion "git-$command"
fi
or is there a reason why it is better to &&-chain the check for
__load_completion with its use?
As for readability, I would prefer my first approach then with the
following reasoning: Checking the existence of a function and actually
calling it can be seen as a unit. Either the function does not exist or
you call it. You could even create a function like "call_if_exists",
that does exactly this. Either way, at the end of the line you are
smarter than before. As for the if-statement, this describes the reason
why you even want to load an external file. If the function in question
($completion_func) already exists, we do not want to load it again. If
you chain the statement with the existence check of __load_completion,
you make it look like those two functions are somehow related, which is
not the case.
To put it in words: "If $completion_func does not already exist, then
load another file (if you know how to do that)." versus "If
$completion_func does not yet exist and you know how to load another
file, then load another file." The difference is subtle, but I think the
first sentence better describes the intention.
Does my reasoning make sense? I mean, the result will be exactly the
same, we are clearly only talking about readability here.
Re: [RFC PATCH 1/1] completion: load completion file for external subcommand
On 2018-04-09 07:59, Junio C Hamano wrote:
>local completion_func="_git_${command//-/_}"
> + if ! declare -f $completion_func >/dev/null 2>/dev/null; then
> + declare -f __load_completion >/dev/null 2>/dev/null &&
> + __load_completion "git-$command"
wouldn't the above be easier to read if it were
if ! declare ... $completion_func ... && declare -f __load_completion
then
__load_completion "git-$command"
fi
or is there a reason why it is better to &&-chain the check for
__load_completion with its use? Same comment applies to the other
hunk.
Good point. I could go even further and ditch the if-construct:
! declare -f $completion_func && declare -f __load_completion &&
__load_completion "git-$command"
I originally intended to do a if-else-construct, which I re-thought
halfway through. I will change that in the next iteration.
Thank you!
--
Regards
Florian
Re: [RFC PATCH 1/1] completion: Load completion file for external subcommand
Ah, sorry, please ignore this one.
[RFC PATCH 0/1] completion: Dynamic completion loading
In this small patch I want to introduce a way to dynamically load completion scripts for external subcommands. A few years ago, you would put a completion script (which defines a Bash function _git_foo for a custom git subcommand foo) into /etc/bash_completion.d, or save it somewhere in your $HOME and source it manually in your .bashrc. Starting with bash-completion v2.0 (or, to be absolutely exact, the preview versions started at v1.90), completion scripts are not sourced at bash startup anymore. Rather, when typing in a command and trigger completion by pressing the TAB key, the new bash-completion's main script looks for a script with the same name as the typed command in the completion directory, sources it, and provides the completions defined in this script. However, that only works for top level commands. After a completion script has been found, the logic is delegated to this script. This means, that the completion of subcommands must be handled by the corresponding completion script. As it is now, git is perfectly able to call custom completion functions, iff they are already defined when calling the git completion. With my patch, git uses an already defined loader function of bash-completion (or continues silently if this function is not found), loads an external completion script, and provides its completions. An example for an external completion script would be /usr/share/bash-completion/completions/git-foo for a git subcommand foo. Florian Gamböck (1): completion: Load completion file for external subcommand contrib/completion/git-completion.bash | 8 1 file changed, 8 insertions(+) -- 2.16.1
[RFC PATCH 1/1] completion: Load completion file for external subcommand
Adding external subcommands to Git is as easy as to put an executable
file git-foo into PATH. Packaging such subcommands for a Linux
distribution can be achieved by unpacking the executable into /usr/bin
of the user's system. Adding system-wide completion scripts for new
subcommands, however, can be a bit tricky.
Since bash-completion started to use dynamical loading of completion
scripts somewhere around v2.0, it is no longer sufficient to drop a
completion script of a subcommand into the standard completions path,
/usr/share/bash-completion/completions, since this script will not be
loaded if called as a git subcommand.
For example, look at https://bugs.gentoo.org/544722. To give a short
summary: The popular git-flow subcommand provides a completion script,
which gets installed as /usr/share/bash-completion/completions/git-flow.
If you now type into a Bash shell:
git flow
You will not get any completions, because bash-completion only loads
completions for git and git has no idea that git-flow is defined in
another file. You have to load this script manually or trigger the
dynamic loader with:
git-flow # Please notice the dash instead of whitespace
This will not complete anything either, because it only defines a Bash
function, without generating completions. But now the correct completion
script has been loaded and the first command can use the completions.
So, the goal is now to teach the git completion script to consider the
possibility of external completion scripts for subcommands, but of
course without breaking current workflows.
I think the easiest method is to use a function that is defined by
bash-completion v2.0+, namely __load_completion. It will take care of
loading the correct script if present. Afterwards, the git completion
script behaves as usual.
This way we can leverage bash-completion's dynamic loading for git
subcommands and make it easier for developers to distribute custom
completion scripts.
Signed-off-by: Florian Gamböck <m...@floga.de>
---
contrib/completion/git-completion.bash | 8
1 file changed, 8 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index b09c8a236..e6114822c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -3096,12 +3096,20 @@ __git_main ()
fi
local completion_func="_git_${command//-/_}"
+ if ! declare -f $completion_func >/dev/null 2>/dev/null; then
+ declare -f __load_completion >/dev/null 2>/dev/null &&
+ __load_completion "git-$command"
+ fi
declare -f $completion_func >/dev/null 2>/dev/null && $completion_func
&& return
local expansion=$(__git_aliased_command "$command")
if [ -n "$expansion" ]; then
words[1]=$expansion
completion_func="_git_${expansion//-/_}"
+ if ! declare -f $completion_func >/dev/null 2>/dev/null; then
+ declare -f __load_completion >/dev/null 2>/dev/null &&
+ __load_completion "git-$expansion"
+ fi
declare -f $completion_func >/dev/null 2>/dev/null &&
$completion_func
fi
}
--
2.16.1
[RFC PATCH 1/1] completion: load completion file for external subcommand
Adding external subcommands to Git is as easy as to put an executable
file git-foo into PATH. Packaging such subcommands for a Linux
distribution can be achieved by unpacking the executable into /usr/bin
of the user's system. Adding system-wide completion scripts for new
subcommands, however, can be a bit tricky.
Since bash-completion started to use dynamical loading of completion
scripts somewhere around v2.0, it is no longer sufficient to drop a
completion script of a subcommand into the standard completions path,
/usr/share/bash-completion/completions, since this script will not be
loaded if called as a git subcommand.
For example, look at https://bugs.gentoo.org/544722. To give a short
summary: The popular git-flow subcommand provides a completion script,
which gets installed as /usr/share/bash-completion/completions/git-flow.
If you now type into a Bash shell:
git flow
You will not get any completions, because bash-completion only loads
completions for git and git has no idea that git-flow is defined in
another file. You have to load this script manually or trigger the
dynamic loader with:
git-flow # Please notice the dash instead of whitespace
This will not complete anything either, because it only defines a Bash
function, without generating completions. But now the correct completion
script has been loaded and the first command can use the completions.
So, the goal is now to teach the git completion script to consider the
possibility of external completion scripts for subcommands, but of
course without breaking current workflows.
I think the easiest method is to use a function that is defined by
bash-completion v2.0+, namely __load_completion. It will take care of
loading the correct script if present. Afterwards, the git completion
script behaves as usual.
This way we can leverage bash-completion's dynamic loading for git
subcommands and make it easier for developers to distribute custom
completion scripts.
Signed-off-by: Florian Gamböck <m...@floga.de>
---
contrib/completion/git-completion.bash | 8
1 file changed, 8 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index b09c8a236..e6114822c 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -3096,12 +3096,20 @@ __git_main ()
fi
local completion_func="_git_${command//-/_}"
+ if ! declare -f $completion_func >/dev/null 2>/dev/null; then
+ declare -f __load_completion >/dev/null 2>/dev/null &&
+ __load_completion "git-$command"
+ fi
declare -f $completion_func >/dev/null 2>/dev/null && $completion_func
&& return
local expansion=$(__git_aliased_command "$command")
if [ -n "$expansion" ]; then
words[1]=$expansion
completion_func="_git_${expansion//-/_}"
+ if ! declare -f $completion_func >/dev/null 2>/dev/null; then
+ declare -f __load_completion >/dev/null 2>/dev/null &&
+ __load_completion "git-$expansion"
+ fi
declare -f $completion_func >/dev/null 2>/dev/null &&
$completion_func
fi
}
--
2.16.1
