Could anyone please confirm to me whether tab completion rules e.g. in Debian/Devuan/Ubuntu Linux have changed some time ago - and how (or from which debian package revision) I could quickly get the old behaviour back?
Details:
I have the impression that tab completion in bash has changed:
- Old: completion always stopped at the next slash (i.e. before entering the next subdirectory):
cd /m<tab> would produce: cd /mnt/ and stop there. Always.
- New: completion proceeds as far down into the path as possible, adding all characters that are identical for all files or further subdirs currently contained in the next subdirectory.
cd /m<tab> would produce: cd /mnt/sd
on a machine where /mnt/ contained only sdb, sdc
but would produce: cd /mnt/s
on a machine where /mnt/ contained sdb, sr0
but would produce: cd /mnt/
on a machine where /mnt/ contained sdb, fda
[These path names are merely simple examples. I know UUIDs - different story, that would infer even less predictability anyway.]
The new behaviour is annoying, because at which position it stops for new user input, depends on the (variable) content of the following subdir(s).
For example, to mount something to /mnt/sdb1,
I might have to type:
... /m<tab>1 on one machine, but
... /m<tab>b1 on another, or
... /m<tab>sdb1 on yet another.
And to know how far autocompletion took me, and what I had to type next, I would have to look at the screen after each and every usage of <tab>.
Sorry, that's plainly unusable.
In the old behaviour, I could compose long pathnames by invariably beginning with the first n character(s) of desired names (which I know) at each new directory level. This worked very fast and completely without looking at the screen - completely independent of the actual contents of the next subdir.
Breaks would only occur, when the number of chars I typed were insufficient for the next <tab>; the beep would tell me, and I could simply add another char still without looking - or check what's available with another <tab>.
The new behaviour, however, may add zero, or one, or more characters after the next slash - or even advance straight through one or more additional subdirectory levels - completely depending on the files available down there. - So after each and every <tab>: nobody would know in advance how far it would take them, and where they would have to continue typing the desired path name - without looking at the screen first.
This new behaviour completely breaks any blind-typing-workflow. I cannot compose (even completely known!) pathnames fast with autocompletion any more - without constantly checking back how far it took me and figuring out which character to type next. - This turns autocompletion from a reliable speedup into a hindrance.
Btw., from the theoretical side: To get somewhere fast,...
...the old behaviour needed you to know where you wanted to go. And would get you there fast and reliably by typing a completely foreseeable character sequence.
...the new behaviour needs you to know where you want to go - but also, everything else that might be around (because that influences how far the next <tab> will take you). - That's impossible (sic!). Therefore, it requires you to check how far you got after each <tab>, and only therafter to figure out which character to type next to continue. - Brrr.
I assume the "maximum possible" completion was meant as an "improvement" or even labeled "more intelligent".
But as usual in recent years, this "improvement" achieves the opposite - by replacing simple deterministic behaviour by one that can't be mechanically used - without constantly checking and processing screen output first.
I've already read other autocompletion related postings and might look at the rules below
/etc/bash_completion*
Before trying that, I'd be grateful for a confirmation that there really was a change; and even more for a simple notion about when (or why) that happened. I would then try whether the installation of some older bash_completion package might correct the problem.
I'd be even happier if my consideration regarding the usability of both approaches could be carefully reviewed, and the old rules re-established as default shipping behaviour.
Sorry for the lengthy description. I wanted to ensure that even the makers of the new autocompletion rules might understand the problem.
Thanks for consideration and for any hint in advance - Joerg
