Hello there,
while bash completion was working great to me in CentOS6, since I'm using C7 I spend my day stuck on completion not working the way it should.
The bad situations I'm facing are: - it doesn't expand *foo whereas there are *foo-named files in current dir, for instance: # rm *foo will show nothing whereas there's a file barfoo in curdir.
- completion takes 10 sec to propose me something, I don't have an example right here but I'd prefer no completion instead of a completion that hangs for more than 3 sec.
I don't care much about command-specific completion (command --switches and so on), but it generally fails in listing files in curdir, that is a huge fail to me.
I have this installed: bash-4.2.46-30.el7.x86_64 bash-completion-2.1-6.el7.noarch bash-completion-extras-2.1-11.el7.noarch
Didn't touch global or user prefs around bash completion if there are.
Am I missing something or is it just an itchy fail, real pain in the *ss?
Regards,
On 08/28/2018 11:33 PM, wwp wrote:
- it doesn't expand *foo whereas there are *foo-named files in current dir, for instance: # rm *foo will show nothing whereas there's a file barfoo in curdir.
Tab completion finishes a single word, given a string that appears at the beginning of a list of candidates.
Wildcard expansion (Ctrl+x, e) will expand a word containing a wildcard to multiple words on the command line, usually so that you can remove some matches.
Neither will do specifically what you're trying to do, as far as I know. I think it's simply too ambiguous.
- completion takes 10 sec to propose me something, I don't have an example right here but I'd prefer no completion instead of a completion that hangs for more than 3 sec.
Some completions can take a while. For example, tab completing a path on a remote system in an scp command, or completing a local path if it's matched against command output rather than the filesystem. IIRC, if you run "git diff path/...", the shell will use the output of "git status" to determine which paths have changed.
I don't know any way to set an upper limit on completions, and while "complete -r <cmd>" is expected to disable programmable completion for a single command, I can't actually clear completion for the ssh/scp commands on my laptop. "complete -r" turns off programmable completion entirely, in which case you simply have simple local path completion, if you'd honestly rather not have potentially slow options.
Hello Gordon,
On Wed, 29 Aug 2018 08:27:06 -0700 Gordon Messmer gordon.messmer@gmail.com wrote:
On 08/28/2018 11:33 PM, wwp wrote:
- it doesn't expand *foo whereas there are *foo-named files in current dir, for instance: # rm *foo will show nothing whereas there's a file barfoo in curdir.
Tab completion finishes a single word, given a string that appears at the beginning of a list of candidates.
Wrong, tab completion proposes the list of candidates if there are several, and it only finishes a single word automatically if there's only one match for the pattern. At least I never experienced tab completion how you're describing it.
Wildcard expansion (Ctrl+x, e) will expand a word containing a wildcard to multiple words on the command line, usually so that you can remove some matches.
Neither will do specifically what you're trying to do, as far as I know. I think it's simply too ambiguous.
This works fine in CentOS 6, and anywhere with bash 2 and 3, I used such completion pattern (ls *foo) for years on various systems. I hardly see how this is ambiguous unless completion doesn't prioritize *foo matching on files.
- completion takes 10 sec to propose me something, I don't have an example right here but I'd prefer no completion instead of a completion that hangs for more than 3 sec.
Some completions can take a while. For example, tab completing a path on a remote system in an scp command, or completing a local path if it's matched against command output rather than the filesystem. IIRC, if you run "git diff path/...", the shell will use the output of "git status" to determine which paths have changed.
Irrelevant example here, I'm not talking about remote shells. On a remote shell I would expect extra delays, anyway, but this is not what I'm dealing with here.
I don't know any way to set an upper limit on completions, and while "complete -r <cmd>" is expected to disable programmable completion for a single command, I can't actually clear completion for the ssh/scp commands on my laptop. "complete -r" turns off programmable completion entirely, in which case you simply have simple local path completion, if you'd honestly rather not have potentially slow options.
I tried disabling programmable completion entirely (`complete -r`), since I don't need it and find it unreliable and it now works as always for file matching patterns. That was a tip, thanks!
Regards,
On 08/29/2018 09:22 AM, wwp wrote:
On Wed, 29 Aug 2018 08:27:06 -0700 Gordon Messmer gordon.messmer@gmail.com wrote:
On 08/28/2018 11:33 PM, wwp wrote:
- it doesn't expand *foo whereas there are *foo-named files in current dir, for instance: # rm *foo will show nothing whereas there's a file barfoo in curdir.
Tab completion finishes a single word, given a string that appears at the beginning of a list of candidates.
Wrong, tab completion proposes the list of candidates if there are several, and it only finishes a single word automatically if there's only one match for the pattern. At least I never experienced tab completion how you're describing it.
Perhaps a miscommunication. What I mean is that tab completion's final outcome would be a single word, though it can suggest multiple candidates if there are several with matching prefix strings.
Wildcard expansion (Ctrl+x, e) will expand a word containing a wildcard to multiple words on the command line, usually so that you can remove some matches.
Neither will do specifically what you're trying to do, as far as I know. I think it's simply too ambiguous.
This works fine in CentOS 6
$ docker run -i -t --rm centos:6 /bin/bash --login [root@9880736fa3ce ~]# touch 1.foo-named [root@9880736fa3ce ~]# touch 2.foo-named [root@9880736fa3ce ~]# ls *.fo
Tab completion doesn't work the way you're suggesting, on CentOS 6. It's possible that such a feature exists in some shell, but not one that I'm aware of.
Hi Gordon,
On Wed, 29 Aug 2018 17:59:58 -0700 Gordon Messmer gordon.messmer@gmail.com wrote:
On 08/29/2018 09:22 AM, wwp wrote:
On Wed, 29 Aug 2018 08:27:06 -0700 Gordon Messmer <gordon.messmer@gmail.c
om> wrote:
On 08/28/2018 11:33 PM, wwp wrote:
- it doesn't expand *foo whereas there are *foo-named files in curre
nt dir, for instance:
# rm *foo will show nothing whereas there's a file barfoo in curdir.Tab completion finishes a single word, given a string that appears at th
e beginning of a list of candidates.
Wrong, tab completion proposes the list of candidates if there are several, and it only finishes a single word automatically if there's only one match for the pattern. At least I never experienced tab completion how you're describing it.
Perhaps a miscommunication. What I mean is that tab completion's final outcome would be a single word, though it can suggest multiple candidates if there are several with matching prefix strings.
Wildcard expansion (Ctrl+x, e) will expand a word containing a wildcard to multiple words on the command line, usually so that you can remove some matches.
Neither will do specifically what you're trying to do, as far as I know.
I think it's simply too ambiguous.
This works fine in CentOS 6
$ docker run -i -t --rm centos:6 /bin/bash --login [root@9880736fa3ce ~]# touch 1.foo-named [root@9880736fa3ce ~]# touch 2.foo-named [root@9880736fa3ce ~]# ls *.fo
Tab completion doesn't work the way you're suggesting, on CentOS 6. It's possible that such a feature exists in some shell, but not one that I'm aware of.
Hah. You may laugh, but talking about mis-communication, you're definitely right. In my former saying "there are *foo-named files in current dir", I didn't mean that I had files like: 1.foo-named 2.foo-named but files named like *foo (IOW, maching the pattern *foo), id est: 1.foo 2.foo (my use of "-named" was confusing obviously) thus, from `ls *foo<TAB>` I was expecting: 1.foo 2.foo I well know that to match "1.foo-named", I should use `ls *foo*<TAB>` (trailing *) and I'm sure that you know that `ls *foo<TAB>` matches 1.foo.
I think we did now understand each other? ;-) to me, the subject is over, I've did `complete -r` and voila.
Regards,
On 08/30/2018 01:11 AM, wwp wrote:
I well know that to match "1.foo-named", I should use `ls*foo*<TAB>` (trailing *) and I'm sure that you know that `ls *foo<TAB>` matches 1.foo.
I didn't. Given a better description of what you're trying to do, I see that the bash's behavior has changed.
I also learned about "Alt+g" and "Ctrl+x g". Those seem to do more or less what you want. These are documented in the bash man page under Completing/Miscellaneous, as glob-complete-word and glob-list-expansions.
Hello Gordon,
On Thu, 30 Aug 2018 15:00:41 -0700 Gordon Messmer gordon.messmer@gmail.com wrote:
On 08/30/2018 01:11 AM, wwp wrote:
I well know that to match "1.foo-named", I should use `ls*foo*<TAB>` (trailing *) and I'm sure that you know that `ls *foo<TAB>` matches 1.foo.
I didn't. Given a better description of what you're trying to do, I see that the bash's behavior has changed.
I'm afraid I see the same behaviour since Bash 2.0 :-/.
I also learned about "Alt+g" and "Ctrl+x g". Those seem to do more or less what you want. These are documented in the bash man page under Completing/Miscellaneous, as glob-complete-word and glob-list-expansions.
Must confess that I quite never use Alt+ and Ctrl+ key combinations, saving me from finger stretching.. I'm reading the man about all that now, instructive, thanks!
Regards,
On Wed, 29 Aug 2018, wwp wrote:
while bash completion was working great to me in CentOS6, since I'm using C7 I spend my day stuck on completion not working the way it should.
Since you don't want what it provides you can either remove the bash-completions* packages or append "complete -r" to your ~/.bashrc which turns off all custom completions leaving just pathname completion -- I also use "complete -o dirnames cd" so that the completions for the cd command are limited to directory names. The bash-completions project didn't stand still nor did the tools it uses so you might consider submitting an upstream bug report.
/mark
Hello Mark,
On Wed, 29 Aug 2018 15:20:45 -0700 (PDT) Mark Milhollan mlm@pixelgate.net wrote:
On Wed, 29 Aug 2018, wwp wrote:
while bash completion was working great to me in CentOS6, since I'm using C7 I spend my day stuck on completion not working the way it should.
Since you don't want what it provides you can either remove the bash-completions* packages or append "complete -r" to your ~/.bashrc which turns off all custom completions leaving just pathname completion -- I also use "complete -o dirnames cd" so that the completions for the cd command are limited to directory names. The bash-completions project didn't stand still nor did the tools it uses so you might consider submitting an upstream bug report.
Yes probably. In fact, I think I got twisted by the name "bash completion", I thought it was just what one can call tab-completion, that we had for years (and often use!). Obviously it's another thing sitting on top of it, that I don't need :-).
Regards,
-
Gordon Messmer -
Mark Milhollan -
wwp