Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
I forgot to explicitly mention the TABs... On 11 Nov 2018, Gabriel F. T. Gomes wrote: >3) bash-completion 2.8-3 > + additional change [1] > + `set show-all-if-ambiguous off' in ~/.inputrc > > $ ls /tmp/test/* > bla ble blee > $ ls /tmp/test/* $ ls /tmp/test/*[TAB][TAB] bla ble blee $ ls /tmp/test/* >4) bash-completion 2.8-3 > + additional change [1] > + `set show-all-if-ambiguous on' in ~/.inputrc > > $ ls /tmp/test/* > /tmp/test/bla /tmp/test/ble /tmp/test/blee > $ ls /tmp/test/bl $ ls /tmp/test/*[TAB] /tmp/test/bla /tmp/test/ble /tmp/test/blee $ ls /tmp/test/bl
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
On 10 Nov 2018, Christoph Anton Mitterer wrote: >On Sat, 2018-11-10 at 18:27 -0200, Gabriel F. T. Gomes wrote: > >> That is possible, but it would require a change that has not yet been >> accepted upstream [1]. I have added this information to Debian's >> bash-completion git repository [2], but I'm not yet confident that >> this is the right thing to do, so I will not apply this to Debian. > >Just curios, why not? > >If one completes without the glob, the completion already shows the >alternatives (which is e.g. like a handy shortcut ls in a directory)... >why not having this with globs in place? I agree that it looks like the correct thing to do, however, I'm always concerned of unintended, undesired side-effects that these changes could have. Particularly for this additional change [1], there has been some discussion around it in the past [2], and, more specifically, Ville Skyttä mentioned what could be the side-effects when someone adds `set show-all-if-ambiguous on' to ~/.inputrc [3]. I gave it a try, and here's what it looks like. $ ls /tmp/test/[ENTER] bla ble blee 1) bash-completion 2.8-3 + `set show-all-if-ambiguous off' in ~/.inputrc $ ls /tmp/test/*[TAB][TAB][TAB][...] (no output) 2) bash-completion 2.8-3 + `set show-all-if-ambiguous on' in ~/.inputrc $ ls /tmp/test/*[TAB][TAB][TAB][...] (no output) Same behaviour on both cases. 3) bash-completion 2.8-3 + additional change [1] + `set show-all-if-ambiguous off' in ~/.inputrc $ ls /tmp/test/* bla ble blee $ ls /tmp/test/* (this is the behaviour you want, I guess) 4) bash-completion 2.8-3 + additional change [1] + `set show-all-if-ambiguous on' in ~/.inputrc $ ls /tmp/test/* /tmp/test/bla /tmp/test/ble /tmp/test/blee $ ls /tmp/test/bl (notice that `*' was expanded to `bl' (common part of the options)) There's a difference in behaviour depending on the setting of `show-all-if-ambiguous'. This inconsistency looks weird to me. Cheers, Gabriel [1] https://superuser.com/questions/823257/unexpected-bash-glob-completion-uses-first-match-even-if-ambiguous/1022284#1022284 [2] https://github.com/scop/bash-completion/pull/77#issuecomment-251582105 [3] https://github.com/scop/bash-completion/pull/77#issuecomment-251728248
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
Hey Gabriel. On Sat, 2018-11-10 at 18:27 -0200, Gabriel F. T. Gomes wrote: > I have backported this patch to Debian's bash-completion and I have > just uploaded a new version, which should show up in sid soon. Awesome :-) Thanks for backporting :-) > > the best (if that was possible) > > would perhaps be if it just *shows* the possible completions, but > > does > > not actually expand to it. > > That is possible, but it would require a change that has not yet been > accepted upstream [1]. I have added this information to Debian's > bash-completion git repository [2], but I'm not yet confident that > this > is the right thing to do, so I will not apply this to Debian. Just curios, why not? If one completes without the glob, the completion already shows the alternatives (which is e.g. like a handy shortcut ls in a directory)... why not having this with globs in place? Cheers, Chris.
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
Hi, Christoph, On 08 Mar 2018, Christoph Anton Mitterer wrote: >Actually I think, it would be even better to just have * not expand by >completion per default (which would often just clutter up the readline >with countless of possible matches)... A bit of good news on this bug... An upstream commit changed the behavior of wildcard completion. Now, completion of wildcards behaves just as you mentioned you would prefer, i.e.: they don't expand to anything. I have backported this patch to Debian's bash-completion and I have just uploaded a new version, which should show up in sid soon. >the best (if that was possible) >would perhaps be if it just *shows* the possible completions, but does >not actually expand to it. That is possible, but it would require a change that has not yet been accepted upstream [1]. I have added this information to Debian's bash-completion git repository [2], but I'm not yet confident that this is the right thing to do, so I will not apply this to Debian. Thanks! [1] https://superuser.com/questions/823257/unexpected-bash-glob-completion-uses-first-match-even-if-ambiguous/1022284#1022284 [2] https://salsa.debian.org/debian/bash-completion/commit/bab51728186237e4204f30860387c2f7511f291c
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
On Wed, 2018-03-07 at 22:14 -0300, Gabriel F. T. Gomes wrote: > I found these two issues upstream, which seem related: > > https://github.com/scop/bash-completion/pull/77 > https://github.com/scop/bash-completion/issues/181 > > It seems that Ville Skyttä is also worried about side-effects: > > https://github.com/scop/bash-completion/pull/77#issuecomment-25158210 > 5 > > > I also found this pair, which also seems related, but I'm not sure it > actually relates to what you're reporting: > > https://github.com/scop/bash-completion/issues/42 > https://github.com/scop/bash-completion/pull/41 Okay...so there possibly are some issues... On Wed, 2018-03-07 at 22:29 -0300, Gabriel F. T. Gomes wrote: > If you do not source bash_completion, then these completions work as > you expect. So maybe you didn't have bash-completion installed? No,.. I'm pretty sure I always had (one of the first things I do ;-) ). But actually, I think, it was not "working" in the sense that it completed to all possible matches, but rather simply left * in place > > What I personally would probably even like more was, if * is just > > not > > completed at all... but completing it only to one "random" match is > > just pointless. > > I agree. Actually I think, it would be even better to just have * not expand by completion per default (which would often just clutter up the readline with countless of possible matches)... the best (if that was possible) would perhaps be if it just *shows* the possible completions, but does not actually expand to it. But that would of course be just my personal preference. Cheers, Chris.
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
On 08 Mar 2018, Christoph Anton Mitterer wrote: >At least I think to remember that this wasn't always buggy... it only >happened in to investigate ^^>. If you do not source bash_completion, then these completions work as you expect. So maybe you didn't have bash-completion installed? >I cannot really say for sure whether there are undesired side >effects... I guess that's the hard part... Proving something to be free of errors. Maybe it's even impossible to prove. >I mean bash-completion should anyway only be active in >interactive sessions, right? So scripts shouldn't take any harm. >And for interactive sessions (or such who kinda hack a script to behave >like in an interactive one)... people must always expect that such >changes occur in new versions. That's a good point. >What I personally would probably even like more was, if * is just not >completed at all... but completing it only to one "random" match is >just pointless. I agree.
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
On 07 Mar 2018, Gabriel F. T. Gomes wrote: >On 27 Feb 2018, Christoph Anton Mitterer wrote: > >>https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1387057 > >While I understand that this patch in launchpad fixes the reported >behaviour, I don't understand why upstream did not want to accept it. >Could there be unintended/undesired side-effects? I found these two issues upstream, which seem related: https://github.com/scop/bash-completion/pull/77 https://github.com/scop/bash-completion/issues/181 It seems that Ville Skyttä is also worried about side-effects: https://github.com/scop/bash-completion/pull/77#issuecomment-251582105 I also found this pair, which also seems related, but I'm not sure it actually relates to what you're reporting: https://github.com/scop/bash-completion/issues/42 https://github.com/scop/bash-completion/pull/41
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
Hey Gabriel On Wed, 2018-03-07 at 21:44 -0300, Gabriel F. T. Gomes wrote: > While I understand that this patch in launchpad fixes the reported > behaviour, I don't understand why upstream did not want to accept it. > Could there be unintended/undesired side-effects? Uhm.. to be honest I haven't even noticed that upstream doesn't want to accept it? :-D At least I think to remember that this wasn't always buggy... it only happened in . I cannot really say for sure whether there are undesired side effects... I mean bash-completion should anyway only be active in interactive sessions, right? So scripts shouldn't take any harm. And for interactive sessions (or such who kinda hack a script to behave like in an interactive one)... people must always expect that such changes occur in new versions. > I could definitely apply this to the Debian package, but I want to > take > this questioning upstream first. It's been a long time, and maybe > they > have a better understanding of the problem, now. Thanks a lot for taking the effort :-) What I personally would probably even like more was, if * is just not completed at all... but completing it only to one "random" match is just pointless. Thanks, Chris.
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
On 27 Feb 2018, Christoph Anton Mitterer wrote: >When completing e.g. >$ ls * > >then * doesn't become all the files (not starting with a .), but >instead only one of the files in the directory. > >This bug exists now since quite a while, and other bug reports, seem to >include the reason (missing quotes in one of the bash-completion >files): > >https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1387057 While I understand that this patch in launchpad fixes the reported behaviour, I don't understand why upstream did not want to accept it. Could there be unintended/undesired side-effects? >https://superuser.com/questions/823257/unexpected-bash-glob-completion-uses-first-match-even-if-ambiguous > >Could this be fixed in the Debian package? :-) I could definitely apply this to the Debian package, but I want to take this questioning upstream first. It's been a long time, and maybe they have a better understanding of the problem, now. I don't have a good understanding of the problem, myself. :) Thanks for reporting.
Bug#891667: bash-completion: file wildcard (*) completion picks up only first match
Package: bash-completion Version: 1:2.7-1 Severity: normal Hi. When completing e.g. $ ls * then * doesn't become all the files (not starting with a .), but instead only one of the files in the directory. This bug exists now since quite a while, and other bug reports, seem to include the reason (missing quotes in one of the bash-completion files): https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1387057 https://superuser.com/questions/823257/unexpected-bash-glob-completion-uses-first-match-even-if-ambiguous Could this be fixed in the Debian package? :-) Thanks, Chris.
