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, -- wwp -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20180829/eff2473f/attachment-0001.sig>
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 at 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, -- wwp -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20180829/30292e72/attachment-0001.sig>
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 at 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, -- wwp -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20180830/538c8d7c/attachment-0001.sig>