Robust detection of end of prompt

[egmontkob]

Is there an existing issue for this?

• I have searched the existing issues

Midnight Commander version and build configuration

4.8.33, git

Operating system

any

Is this issue reproducible using the latest version of Midnight Commander?

• I confirm the issue is still reproducible with the latest version of Midnight Commander

How to reproduce

We don't have a way to reliably detect when the subshell has finished printing its prompt.

Yet, at some point, when a command that we launched from mc's panels finishes, we have to decide to show the panels.

It looks to me that currently we're relying on heuristics, e.g. whatever that arrives in a single read() or something similar. This already causes problems (e.g. #4843; there were more but I'm just lost :))

Let's try to find a way to reliably detect when the subshell has finished printing the prompt; replace some of these heuristics by reliable solutions.

Expected behavior

.

Actual behavior

.

Additional context

No response

[egmontkob]

One method that has been proposed by Ossi is to append some marker to the end of the prompt.

We could filter that trafic and stop that string from appearing on the host terminal.

---

Something we need to address though: If the shell's belief about the cursor column is faulty then command line editing will fall apart. So this sequence at the end of the prompt has to be something that the shell believes won't advance the cursor.

bash has \[ \] markers in the prompt. zsh has %{ %}. These are good.

fish: haven't checked, but being a modern shell I expect it supports something similar.

dash doesn't have line editing, the kernel stays in cooked mode. This means no problem for us, swallowing some characters from the prompt doesn't change anything.

I can't remember which shell it was that I tested last night (busybox ash? ksh? mksh?) that doesn't have such special markers, but automatically recognizes SGR \e[...m escape sequences. So our marker could be an SGR sequence, one that's somewhat nonsensical and thus has no real chance of actually appearing in a prompt (something like \e[999;999;0;00;000m).

tcsh: Of course it's the one that doesn't support it. It has %{string%} but "This cannot be the last sequence in prompt" -- why, oh why?? We could try to contact its developers to remove this seemingly pointless limitation, which, if they accept, would only work on systems with brand new tcsh and we'd still need to make sure not to break with older versions.

[egmontkob]

Another method that occurred to me:

After a command finishes and we're notified of it via SIGCHLD, do a tcflush() to make sure there's no keypress stuck in the channel that the shell would execute, then send an Enter to trigger yet another prompt (preceded by another SIGCHLD synchronization).

This way we'd perfectly and reliably know where the first prompt ends, and could use that prompt for all our purposes. We'd discard (not forward the data to the host, etc.) the second prompt. We wouldn't know when the shell finishes printing the second prompt, but since we're ignoring it anyway, it would hopefully not cause any problems.

[zyv]

We wouldn't know when the shell finishes printing the second prompt, but since we're ignoring it anyway, it would hopefully not cause any problems.

Interesting idea. I really wonder if ignoring the second prompt print time can cause any trouble?