From: Ella Ma <xutong.ma@inria.fr>
To: cocci@inria.fr
Subject: [cocci] RFC: Fix on bash completion script for `_spatch not found` issue
Date: Wed, 4 Dec 2024 13:13:34 +0100 (CET) [thread overview]
Message-ID: <820693222.25218599.1733314414146.JavaMail.zimbra@inria.fr> (raw)
Hi all,
In another email, Victor Gambier mentioned that
>> I also noticed weird things around bash autocompletion. Regardless of
>> whether or not the autocompletion finds any matches, if your command
>> started with "spatch", the line "bash: completion: function `_spatch'
>> not found" will show up. I think that could be related to the standard
>> stream weirdness. To be more precise:
>>
>> $ spatch /h
>> + [TAB]
>> will transform into:
>>
>> $ spatch /hbash: completion: function `_spatch' not found
>> $ spatch /home/
So I checked the bash completion script for spatch (scripts/spatch.bash_completion)
and found this
```scripts/spatch.bash_completion
...
have spatch &&
_spatch() { ... } # function body omitted for simplicity
complete -F _spatch ... spatch
...
```
The `have` command will check whether the argument is an executable in PATH
or a function defined in the current context.
In our case, the `have` command checks whether `spatch` command is available.
If not, the complete function `_spatch` will not be defined.
But, no matter whether the `have` check passes or not,
function `_spatch` will always be assigned for the completion of spatch.
So, if it is not defined, we will encounter the problem we observed now.
I think this may be due to the order of
(1) adding the path of spatch to PATH (the opam switch dir or other prefixes), and
(2) loading bash completion files.
I did not dig deeply into the order which happens first.
But I believe its the problem of PATH variable according to what we have observed now.
So, I suggest removing the `have` check protecting the definition of function _spatch.
I propose this solution because all the complete scripts in the system,
i.e. /etc/bash_completion.d and /usr/share/bash-completion/completions,
do not perform the `have` check;
and if spatch is installed to opam switch root, the `have` check may never pass,
as the opam paths are appended to the end of the $HOME/.bashrc file.
What do you think? Any suggestions are welcome.
ella
P.S.: Suggested patch:
```
diff --git a/scripts/spatch.bash_completion b/scripts/spatch.bash_completion
index ae217af9e..3ff48d9c7 100644
--- a/scripts/spatch.bash_completion
+++ b/scripts/spatch.bash_completion
@@ -34,7 +34,6 @@ __spatchcomp_1 ()
done
}
-have spatch &&
_spatch()
{
local cur prev xspec
```
reply other threads:[~2024-12-04 12:13 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=820693222.25218599.1733314414146.JavaMail.zimbra@inria.fr \
--to=xutong.ma@inria.fr \
--cc=cocci@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).