On Wed, Jul 15, 2015 at 04:28:13PM +0200, Rickard Norlander wrote:
> Description:
> If a file is created which has a newline in its filename, tab
> completion does not work correctly. The part before, and the part after the
> newline behave as separate entries for the purpose of completion.
It works for me in 4.3.39 as long as the portion before the newline
is unique. E.g. if I have 'bad' and $'bad\nfile' then completion stops
at 'bad' and there is no way to enter the newline without beginning a
new completion. But see below.
But if I have a file that doesn't partially match any others
(like $'xyz\nabc') then it's fine.
> Repeat-By:
> First, run
>
> mkdir folder;cd folder;echo $'#include<stdio.h>\nint
> main(){fopen("Hello\\nHenrik","w");}'>a.c;gcc a.c;./a.out
It's much easier to use
$ touch $'Hello\nHenrik'
to create such files for testing purposes.
==========================
OK, after a bit more testing, there is certainly something interesting
here that I don't quite understand, but which Chet probably will.
I have two files: 'bad' and $'bad\nfile'
I type:
$ cat bad
and press Tab twice. (The first does nothing visible.) This gives me
two completion choices:
bad bad^Jfile
If I press Ctrl-V Ctrl-J, the cursor moves to the next line. At this
point, further Tabbing (with or without characters) acts like a new
completion rather than a continuation of the previous completion, as
this bug report indicated.
But if instead I type:
$ cat 'bad
and then press Tab twice, I get the same completion choices:
bad bad^Jfile
Then if I press Ctrl-V Ctrl-J Tab, I end up with:
$ cat 'bad
file'
So, quoting the filename works around the bug, but readline isn't quite
clever enough to do that on its own yet.
