-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Question: is there a way to source completion files always and not just on-demand #1055
Comments
Oh and I should add: I was specifically looking for some place in I mean there's: bash-completion/bash_completion Lines 3206 to 3223 in f260fa8
but |
Oh and last but not least: There might be more potential users for such functionality. E.g. again in Debian there's For something in |
One option is to put it in a compat directory. The compat directory can be configured by $ pkg-config bash-completion --variable compatdir If you clone the bash-completion directory in your home directory, it would be Another option is to put it in # ~/.bashrc
# something like this (Please examine it. I haven't tested it)
for _bashrc_profile_script in ~/.profile.d/*.{sh,bash}; do
if [[ -f $_bashrc_profile_script ]]; then
source "$_bashrc_profile_script"
fi
done
unset -v _bashrc_profile_script Or one of the easiest solutions is to source the file directly from # ~/.bashrc
source /path/to/your/fzf.sh |
This is a general problem that also happens with # ~/.bashrc
function source {
if [[ $1 == ?(*/)your-exclude-pattern ]]; then
return 1
fi
builtin source "$@"
}
function . { source "$@"; } This approach can be used for any sourced scripts without being limited to bash-completion auto-loaded files. edit: A drawback is that it can unexpectedly localize global variables declared by |
Let's see. Your first solution is the one that I also found (i.e. Your second proposal (some It works of course, just like your 3rd proposal, which is however also not really suited for some out-of-the-box-installation by a package. Your idea with overriding source is nice, though it's probably not so well suited for end-users - at least not in comparison to e.g. the schema used by systemd, where a config file in For I guess there wouldn't be any interest on the bash-completion side, to implement a schema like systemd does?! If there is (interest), than we could leave this issue open to track that, otherwise, I think my question is answered and the best approach to me seems Thanks :-) |
This is not true. Fzf's In this sense, trying to put fzf's completion script under the control of bash-completion is strange. There is also another Bash configuration provided by fzf:
Isn't it already possible? You can create a symbolic link in You don't seem to be happy with directly adding |
Ah, I see. I hadn't realised that it can be used without bash-completion… but I'm a bit confused now :-D
Which, AFAIU, is bash-completion for the So would the best thing to do be to split up |
plus:
Well my main intention is to get the Debian bug fixed. For that - assuming some out-of-the-box functionality is desired - any modification of files in I personally can in principle also live with putting the file (or better a symlink to it) in either |
No, fzf's
No. The integration with bash-completion (not general Bash completions) is only these lines.
There is no need to put it in
If the rest settings are placed in another place (such as
What is the problem in modifying files in
What do you mean by OOTB in this context? Shouldn't a configuration be enabled by e.g. calling For example, a distribution can define a system-wide directory (such as Also, as a developer, I would like to request packagers not to independently invent a random scheme that is only available in a specific distribution. If you would like to invent a new scheme, I would like to ask packagers to put some effort into discussing it with packagers of all major distributions and introduce the scheme after some agreement. Otherwise, every distribution requires a specific way of configuration, which is a mess from the perspective of the developers of the projects that rely on the setting. In particular, for fzf's shell configurations, the location of the script file is already diverse and troublesome to automatically detect. Here are the related code to detect the location of fzf's shell settings in blesh-contrib:
Before adding even another location that possibly contains fzf's shell settings, you should normalize those locations and form an agreement among the packagers of |
Okay, what I meant was, that
I "only" got in wrong, in that I assumed
I think that's just what I'm trying to find out: The (2) part of
Of course. But he may not even have thought about it yet. So that's why I tried to find out what would be the cleanest way, in order to present that to him.
Well my only point would have been to keep the shell env as clean as possible and load the functions needed for
In principle it would of course work, but I don't think this is currently done, at least not in Debian, by any packages.
Uhm, I thought any such files (that were just in
Sounds definitely reasonable. Actually I'd love to see that, cause I, personally, don't like that one silently gets stuff enabled by packages putting stuff into e.g.
Same here… I agree, but I just try to fix that one bug in a clean manner. |
Hey there.
I was looking at Debian bug #1013356 which is about fzf’s completion file, which Debian installs at
/usr/share/bash-completion/completions/fzf
not being loaded (unless one doesfzf <TAB>
) which however breaks the functionality of that (it's not just completion forfzf
but like a hook that allows completion of arbitrary other things (e.g. SSH hostnames) usingfzf
.So I wondered whether
bash-completion
provides means to have such things sourced in general. Couldn't find anything in the FAQ or previous issues. And I thinkhelpers
aren’t what I'm looking for either.Thanks,
Chris.
The text was updated successfully, but these errors were encountered: