Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-11-11 Thread Gabriel F. T. Gomes
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

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-11-11 Thread Gabriel F. T. Gomes
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

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-11-10 Thread Christoph Anton Mitterer
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

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-11-10 Thread Gabriel F. T. Gomes
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 co

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-03-08 Thread Christoph Anton Mitterer
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: > > h

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-03-07 Thread Gabriel F. T. Gomes
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&report ^^>. If you do not source bash_completion, then these completions work as you expect. So maybe you didn't have bash-completion installed? >I

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-03-07 Thread Gabriel F. T. Gomes
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

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-03-07 Thread Christoph Anton Mitterer
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 e

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-03-07 Thread Gabriel F. T. Gomes
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

Bug#891667: bash-completion: file wildcard (*) completion picks up only first match

2018-02-27 Thread Christoph Anton Mitterer
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