Expand first before asking the question "Display all xxx possibilities?"

[積丹尼 Dan Jacobson]

Instead of

$ zz /jidanni_backups/da<TAB>
Display all 113 possibilities? (y or n) n

and then finally showing

$ zz /jidanni_backups/dan_home_bkp

how about doing the expansion first, so entering
$ zz /jidanni_backups/da<TAB> would then change into
$ zz /jidanni_backups/dan_home_bkp with below it the question
Display all 113 possibilities? (y or n)

[Chet Ramey]

Thanks for the suggestion.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU ch...@case.edu http://tiswww.cwru.edu/~chet/

[Chris Elvidge]

On 05/08/2020 02:55 pm, Chet Ramey wrote:
> On 8/2/20 6:55 PM, 積丹尼 Dan Jacobson wrote:
>> Instead of
>>
>> $ zz /jidanni_backups/da<TAB>
>> Display all 113 possibilities? (y or n) n
>>
>> and then finally showing
>>
>> $ zz /jidanni_backups/dan_home_bkp
>>
>> how about doing the expansion first, so entering
>> $ zz /jidanni_backups/da<TAB> would then change into
>> $ zz /jidanni_backups/dan_home_bkp with below it the question
>> Display all 113 possibilities? (y or n)

What happens if you have:
dan_home-bkp, dan_home_nobkp, dan-home-bkp, dan-nohome-bkp,
dan_nohome-bkp (etc.) in /jidanni_backups/?
Which do you choose for the first expansion?

>
> Thanks for the suggestion.
>


--

Chris Elvidge
England

[Ilkka Virta]

I think they meant the case where all the files matching the given
beginning have a longer prefix in common. The shell expands that prefix
to the command line after asking to show all possibilities.

$ rm *
$ touch dan_home_bkp{1..199}
$ ls -l da[TAB]
Display all 199 possibilities? (y or n) [n]
$ ls -l dan_home_bkp[cursor here]

So the shell has to fill in the common part anyway, and it might as well
do it first, without asking.

(Which just so happens to be what Zsh does...)


--
Ilkka Virta / itv...@iki.fi

[Davide Brini]

On Thu, 6 Aug 2020 15:13:30 +0300, Ilkka Virta <itv...@iki.fi> wrote:

> I think they meant the case where all the files matching the given
> beginning have a longer prefix in common. The shell expands that prefix
> to the command line after asking to show all possibilities.
>
> $ rm *
> $ touch dan_home_bkp{1..199}
> $ ls -l da[TAB]
> Display all 199 possibilities? (y or n) [n]
> $ ls -l dan_home_bkp[cursor here]
>
> So the shell has to fill in the common part anyway, and it might as well
> do it first, without asking.

Don't know about the OP's environment, but it works out of the box for me,
and it always has, as far as I can remember:

$ touch dan_home_bkp{1..199}
$ ls da[TAB]
$ ls dan_home_bkp[TAB][TAB]

Display all 199 possibilities? (y or n)

$ bash --version
GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)

--
D.

[Chet Ramey]

On 8/6/20 8:13 AM, Ilkka Virta wrote:
> On 5.8. 22:21, Chris Elvidge wrote:
>> On 05/08/2020 02:55 pm, Chet Ramey wrote:
>>> On 8/2/20 6:55 PM, 積丹尼 Dan Jacobson wrote:
>>>> how about doing the expansion first, so entering
>>>> $ zz /jidanni_backups/da<TAB> would then change into
>>  >> $ zz /jidanni_backups/dan_home_bkp with below it the question
>>  >> Display all 113 possibilities? (y or n)
>>
>> What happens if you have:
>> dan_home-bkp, dan_home_nobkp, dan-home-bkp, dan-nohome-bkp,
>> dan_nohome-bkp (etc.) in /jidanni_backups/?
>> Which do you choose for the first expansion?
>

> I think they meant the case where all the files matching the given
> beginning have a longer prefix in common. The shell expands that prefix to
> the command line after asking to show all possibilities.

Only if you set the "show-all-if-ambiguous" readline variable explicitly
asking for this behavior. Readline's default behavior is to complete up to
the longest common prefix, then, on the next completion attempt, to note
that there weren't any additional changes to the buffer and ask if the user
wants to see the alternatives. Dan wants a change in the behavior that
variable enables.

[Ilkka Virta]

On 6.8. 15:59, Chet Ramey wrote:
> On 8/6/20 8:13 AM, Ilkka Virta wrote:
>> I think they meant the case where all the files matching the given
>> beginning have a longer prefix in common. The shell expands that prefix to
>> the command line after asking to show all possibilities.
>
> Only if you set the "show-all-if-ambiguous" readline variable explicitly
> asking for this behavior. Readline's default behavior is to complete up to
> the longest common prefix, then, on the next completion attempt, to note
> that there weren't any additional changes to the buffer and ask if the user
> wants to see the alternatives. Dan wants a change in the behavior that
> variable enables.

Right, sorry.

I do have it set because otherwise there's a step where tab-completion
only produces a beep, and doesn't do anything useful. I didn't realize
causes partial completion to be skipped too.

[Chet Ramey]

It's not `skipped'. The partial match gets inserted before you go back to
line editing, when you can actually do something with it. There's no real
good HCI reason to insert it first only to have it scroll off the screen
as readline displays the possible matches, then insert it again before
going on. And say you decline to see the possible matches -- the partial
match gets inserted before you go back to editing anyway.