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 08/29/2018 09:22 AM, wwp wrote:> 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.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 at 9880736fa3ce ~]# touch 1.foo-named [root at 9880736fa3ce ~]# touch 2.foo-named [root at 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 at 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 at 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 at 9880736fa3ce ~]# touch 1.foo-named > [root at 9880736fa3ce ~]# touch 2.foo-named > [root at 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, -- 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/cd9f0aad/attachment-0001.sig>