Dear Debian Team,

I think I found a bug, and I'm writing to this list as I don't know the associated package (according to https://www.debian.org/Bugs/Reporting).
I'm experiencing this bug in konsole (KDE's terminal emulator), but the
same bug has been reported here
https://askubuntu.com/q/1331111
in xfce-terminal on Ubuntu 20.04, so I don't think it is a konsole or a
KDE bug. Maybe the affected package is bash-autocompletion, but I don't
know for sure.


I would like to run okular opening the pdf file
~/dir1\ with\ blanks/dir2/file.pdf
via command line. In konsole I type
okular ~/dir1\ with\ blanks/
and hit the tab key twice for autocomplete. But I won't get offered
dir2. After adding more letters like
okular ~/dir1\ with\ blanks/di
to make the completion to dir2 unique, nothing happens at all after
hitting tab (twice). Only after spelling out the complete directory as
okular ~/dir1\ with\ blanks/dir2
and then hitting tab, autocomplete works again as expected.


My feeling is that there are two components which together trigger this bug.

(1) Blanks in the path.
The blanks in dir1\ with\ blanks, because renaming it to something
without a blank like dir1 makes the problem disappear. Also, note that
adding a blank to dir2 is not a problem.

(2) Automatic filtering of autocompletion candidates.
Starting the command with 'konsole' and then hitting tab will only
complete to pdf files. When I do the same with 'ls' instead of 'okular',
no filtering takes place, and the above problem disappears (meaning that
typing
ls ~/dir1\ with\ blanks/
and hitting TAB twice will offer me dir2.


Relevant packages:

I'm on Debian 12 (stable) amd64.

konsole 4:22.12.3-1
bash 5.2.15-2+b2
bash-completion 1:2.11-6

$ uname -a
Linux goblin 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1
(2023-12-30) x86_64 GNU/Linux

Thank you.

Best,

~Michael

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jan 29, 2024 at 09:32:18AM +0100, Michael Kiermaier wrote:

I would like to run okular opening the pdf file
~/dir1\ with\ blanks/dir2/file.pdf
via command line. In konsole I type
okular ~/dir1\ with\ blanks/
and hit the tab key twice for autocomplete. But I won't get offered
dir2. After adding more letters like

My first question would be: does the problem still occur if you disable bash-completion? Open a new instance of bash and run "complete -r" to
remove all programmable completions. See if the problem still occurs.
Then close that instance of bash.

okular ~/dir1\ with\ blanks/di
to make the completion to dir2 unique

Oh, there's more than one subdir? Let me test that as well....

Yeah, even with both dir1 and dir2 (each containing a file), I still get
the expected behavior in bash without bash-completion in the picture.

unicorn:~$ cd /tmp
unicorn:/tmp$ mkdir -p 'dir with blanks'/dir2
unicorn:/tmp$ touch "$_"/file

(first experiments with tab completion, not shown)

unicorn:/tmp$ mkdir -p 'dir with blanks'/dir1
unicorn:/tmp$ touch "$_"/otherfile
unicorn:/tmp$ xyz dir\ with\ blanks/dir
dir1/ dir2/
unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file

I'm assuming whatever issue you're seeing is the result of a
bash-completion bug, not a bash bug. If you can confirm that, then
you'll know which package to file a bug against.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon 29 Jan 2024 at 07:40:13 (-0500), Greg Wooledge wrote:

On Mon, Jan 29, 2024 at 09:32:18AM +0100, Michael Kiermaier wrote:

I would like to run okular opening the pdf file
~/dir1\ with\ blanks/dir2/file.pdf
via command line. In konsole I type
okular ~/dir1\ with\ blanks/
and hit the tab key twice for autocomplete. But I won't get offered
dir2. After adding more letters like

My first question would be: does the problem still occur if you disable bash-completion? Open a new instance of bash and run "complete -r" to
remove all programmable completions. See if the problem still occurs.
Then close that instance of bash.

okular ~/dir1\ with\ blanks/di
to make the completion to dir2 unique

Oh, there's more than one subdir? Let me test that as well....

Yeah, even with both dir1 and dir2 (each containing a file), I still get
the expected behavior in bash without bash-completion in the picture.

unicorn:~$ cd /tmp
unicorn:/tmp$ mkdir -p 'dir with blanks'/dir2
unicorn:/tmp$ touch "$_"/file

(first experiments with tab completion, not shown)

unicorn:/tmp$ mkdir -p 'dir with blanks'/dir1
unicorn:/tmp$ touch "$_"/otherfile
unicorn:/tmp$ xyz dir\ with\ blanks/dir
dir1/ dir2/
unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file

I'm assuming whatever issue you're seeing is the result of a
bash-completion bug, not a bash bug. If you can confirm that, then
you'll know which package to file a bug against.

Unless I missed a bit in the OP, the bug is actually worse.
Type di and press TAB, and bash-completion gives you
dir\ with\ blanks/ ok. But now rub out the "nks/" at the end
and press TAB. It fails to complete even that directory name.

However, there's a workaround, which you really have to know
about if you're a bash-completion user, and that is:

ESCAPE /

AFAICT you won't get the list of possibilities as you would normally,
but it should autocomplete as far as the string remains unique.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Jan 30, 2024 at 12:05:24AM +0700, Max Nikulin wrote:

On 29/01/2024 19:40, Greg Wooledge wrote:

Let me test that as well....

[...]

unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file

"okular" is important here. Only limited set of file name suffixes are allowed for some commands. You do not need to have okular installed, completion rules are part of bash-completion.

That's my point as well. I'm trying to get the OP to determine whether
it's the programmable completion for "okular" in particular that's at
fault, or bash itself (hint: it's not).

In my demonstration, all programmable completions were disabled. I
never use them to begin with. So, in my demonstration, the command
name is completely irrelevant.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon 29 Jan 2024 at 12:59:39 (-0500), Greg Wooledge wrote:

On Tue, Jan 30, 2024 at 12:05:24AM +0700, Max Nikulin wrote:

On 29/01/2024 19:40, Greg Wooledge wrote:

Let me test that as well....

[...]

unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file

"okular" is important here. Only limited set of file name suffixes are allowed for some commands. You do not need to have okular installed, completion rules are part of bash-completion.

That's my point as well. I'm trying to get the OP to determine whether
it's the programmable completion for "okular" in particular that's at
fault, or bash itself (hint: it's not).

In my demonstration, all programmable completions were disabled. I
never use them to begin with. So, in my demonstration, the command
name is completely irrelevant.

No, it's pretty much any command that wants to match particular
extensions, like xpdf, dvips, unzip, etc. Obviously bash-completion
should always attempt to match directories as it doesn't know what
they might contain.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/29/24 18:59, Greg Wooledge wrote:

On Tue, Jan 30, 2024 at 12:05:24AM +0700, Max Nikulin wrote:

On 29/01/2024 19:40, Greg Wooledge wrote:

Let me test that as well....

[...]

unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file

"okular" is important here. Only limited set of file name suffixes are
allowed for some commands. You do not need to have okular installed,
completion rules are part of bash-completion.

That's my point as well. I'm trying to get the OP to determine whether
it's the programmable completion for "okular" in particular that's at
fault, or bash itself (hint: it's not).

Thank you for your responses! After 'complete -r' the problem
disappears. I should add that I never touched the autocomplete settings.

I will submit a bug report for the package bash-completion.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jan 29, 2024 at 01:51:19PM -0600, David Wright wrote:

On Mon 29 Jan 2024 at 19:31:50 (+0100), Michael Kiermaier wrote:

Thank you for your responses! After 'complete -r' the problem
disappears. I should add that I never touched the autocomplete settings.

No, but you lose your so-called component (2) filtering.

For me, a better workaround is, when the directory path gets "stuck":

. Press HOME,
. Type any letter that makes a "wrong" command name (eg aokular),
. Press END,
. Press TAB and carry on using completion for directory/filenames,
. Once you reach the right directory, and if you need filtering,
press HOME DELETE END and you've got filtering back again.
. Obviously press HOME DELETE if you didn't do the previous step.

I will submit a bug report for the package bash-completion.

complete -r isn't intended as a workaround. It's intended as a diagnostic step.

Seeing the problem go away when completion goes away means that the
problem is *in* the completion. Thus, he knows which package to file
a bug report against.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon 29 Jan 2024 at 19:31:50 (+0100), Michael Kiermaier wrote:

On 1/29/24 18:59, Greg Wooledge wrote:

On Tue, Jan 30, 2024 at 12:05:24AM +0700, Max Nikulin wrote:

On 29/01/2024 19:40, Greg Wooledge wrote:

Let me test that as well....

[...]

unicorn:/tmp$ xyz dir\ with\ blanks/dir2/file

"okular" is important here. Only limited set of file name suffixes are allowed for some commands. You do not need to have okular installed, completion rules are part of bash-completion.

That's my point as well. I'm trying to get the OP to determine whether it's the programmable completion for "okular" in particular that's at fault, or bash itself (hint: it's not).

Thank you for your responses! After 'complete -r' the problem
disappears. I should add that I never touched the autocomplete settings.

No, but you lose your so-called component (2) filtering.

For me, a better workaround is, when the directory path gets "stuck":

. Press HOME,
. Type any letter that makes a "wrong" command name (eg aokular),
. Press END,
. Press TAB and carry on using completion for directory/filenames,
. Once you reach the right directory, and if you need filtering,
press HOME DELETE END and you've got filtering back again.
. Obviously press HOME DELETE if you didn't do the previous step.

I will submit a bug report for the package bash-completion.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/29/24 20:59, Greg Wooledge wrote:

complete -r isn't intended as a workaround. It's intended as a diagnostic step.

Seeing the problem go away when completion goes away means that the
problem is *in* the completion. Thus, he knows which package to file
a bug report against.

Yes, I understood that 'complete -r' is for diagnostics.

I've submitted this bug report now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061831

Thank you again for your help.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue 30 Jan 2024 at 10:34:21 (+0700), Max Nikulin wrote:

On 30/01/2024 02:51, David Wright wrote:

. Press HOME,
. Type any letter that makes a "wrong" command name (eg aokular),
. Press END,

The escape "Esc /" workaround has been posted in this thread already.

Yes, I believe I posted it.

But if you have a long path with many ambiguous branches along the
way, using Esc / gets very tedious because you get no help with
choosing what character to write next. Tab Tab doesn't do anything
until you reach a directory with "candidates" in it (ie files with
appropriate extensions).

But even then, Tab Tab does the wrong thing. It only lists the
candidates, not any directories that can continue the path further.

However, using my "wrong" command method, Tab Tab lists are complete
all the way down the path. You can then correct the command in order
to prune the Tab Tab listing to include just the candidates
(and in preparation for actually executing the command, of course).

It uses built-in readline path completion instead of BASH programmable completion. It may be available as [Alt+/] (in xterm it requires xterm*vt100.metaSendsEscape: true)

[Ctrl+A] and [Ctrl+E] are alternatives for [Home] and [End].

For details see the BASH manual

info '(bash) Commands For Completion'

"complete-filename" function and other sections related to readline
and completion. https://www.gnu.org/software/bash/manual/html_node/Commands-For-Completion.html#index-complete_002dfilename-_0028M_002d_002f_0029

To Greg: Thanks for explaining Michael's true motives.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)