Warn if directory cannot be read

[jidanni]

$ sudo cat /var/log/exim4/<TAB> shows nothing.

I see,

$ ls -dl /var/log/exim4
drwxr-s--- 1 Debian-exim adm 14 2024-05-19  /var/log/exim4

it can't read it.

OK, how about a message:

Bash Completion: unable to read directory /var/log/exim4

[akinomyoga]

Where can we show the message? If we output it to the terminal, it confuses Readline and causes a broken layout.

[akinomyoga]

As I wrote in #1364 (comment), internally generating messages might be useful for other frameworks.

[jidanni]

Where can we show the message? If we output it to the terminal, it confuses Readline and causes a broken layout.

If you're unable to write to standard error then there's a bigger problem!

[akinomyoga]

OK, you are right. Of course, we can write to the standard error technically. What I meant is that we shouldn't write to the standard error.

[jidanni]

Naa... just prefix it with "Bash completion: ...." that way the user knows where it is coming from.

[akinomyoga]

The user would know who breaks the terminal cursor position, but Readline doesn't have a way to know the fact that something was output in the terminal display, and Readline cannot recover the cursor position.

[jidanni]

How about:
Bash Completions is about to show a 27 character error message.
OK, it does it.
And now Bash Completion sends an additional 27 ANSI termcap 'go back' characters, to get the cursor in the right spot again.

[akinomyoga]

I'm actually unsure about whether I understand what you mean, but

How about:
Bash Completions is about to show a 27 character error message.
OK, it does it.

I've been writing that it's not OK.

And now Bash Completion sends an additional 27 ANSI termcap 'go back' characters, to get the cursor in the right spot again.

What do you specifically mean by "ANSI termcap 'go back'"? ANSI is not termcap, and there isn't anything called "go back" in ANSI nor termcap, though there are multiple entries that you possibly mean. If you talk about termcap le, which is typically set to ANSI CUB, you can't go back to the original position with that when line breaking is involved. It's the same with termcap LE. Another possibility could be termcap sc/rc, but that may overwrite the position that Readline possibly sets. Even if Readline doesn't set sc, it may still conflict with other settings that use it.

In addition, that doesn't solve the issue

Readline doesn't have a way to know the fact that something was output in the terminal display,

Then, the terminal contents rendered by Readline and the message written to the terminal from the completion setting would overlap with each other.

Readline simply doesn't provide the support for such a case.

[jidanni]

Maybe just be sure no newlines are in those 27 characters, then you are on the same line.
Or do the opposite, and put a newline as your first character, making sure the user sees the message.

Anyway all other programs I know of just spew out error messages, knowing the user will be grateful, even if it disrupts the screen.

I mean it is the terminal!! That's what terminals are for. You aren't ever in danger of injecting mess into the user's files, because you are writing to stderr.

[akinomyoga]

Maybe just be sure no newlines are in those 27 characters, then you are on the same line.

I'm not talking about the case where the 27 characters contain the newline. I'm talking about the line wrapping of the terminal.

Or do the opposite, and put a newline as your first character, making sure the user sees the message.

If you do that, it's impossible to go back to the original column because the newline will lose that information. Going left by 27 terminal cells only positions the cursor at the beginning of the terminal line, which is inconsistent with Readline's internal state.

Anyway all other programs I know of just spew out error messages, knowing the user will be grateful, even if it disrupts the screen.

I don't know any programs that send messages intended to be shown during Bash completion. Could you show an example? Or do you consider the programs that work independently of Readline? If a program is the only one that outputs strings to the terminal, there isn't a problem at all. The current issue is that Readline is supposed to have control of the terminal contents, where other programs shouldn't disturb it. Or if you talk about a broken completion setting that fails and outputs error messages, that's just a bug. As far as I know, no completion settings intend to show completion messages by writing to the standard error.

I mean it is the terminal!! That's what terminals are for.

Yes, but when multiple programs cooperate in one terminal, those programs need to follow certain rules depending on their role. If you start a background process yes & in ~/.bashrc, you'll not be able to work with such sessions. You might think that completion settings may intentionally break the terminal contents, but most users don't think so. If any users report it, the only thing we can do is to simply remove the message. Then, we don't bother adding the message from the beginning.

You aren't ever in danger of injecting mess into the user's files, because you are writing to stderr.

Yeah, it's not dangerous in the same sense that putting yes & in your ~/.bashrc isn't dangerous. Anyway, I'm not saying that the issue is that it's dangerous. Whether it's safe or dangerous is irrelevant to whether completion settings should output messages to the terminal when Readline is in front.