Linux console + console output lines => wrong accents; retire `CONSOLE_CONTENTS`?

[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

Linux

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

On the Linux virtual terminal (console), with UTF-8 locale, set F9 -> Options -> Layout -> Console output Output Lines to some positive value.

Run a command that prints some accented chars.

Notice that the accented letters are shown incorrectly.

---

mc queries the contents from cons.saver using the CONSOLE_CONTENTS commands in show_console_contents_linux. The 8-bit character from received data (in some ad-hoc encoding, probably a runtime "palette" approach) is then passed to tty_print_char() which expects a char accoding to the locale (practically Unicode).

We could probably fix it by reading /dev/vcsu* (the Unicode-aware counterpart of /dev/vcsa*, available since Linux 4.19, October 2018; but reading that file fails if the console is not in Unicode mode, so we'd have to retain a fallback).

But is it worth it?

In my opinion the Linux console is only suitable for emergency firefighting; for all purposes pretty much any graphical terminal emulator is vastly superior. I don't think mc should aim for having features that aren't available on graphical terminals.

Also, security/privacy-wise, it slightly worries me that setgid cons.saver offers the functionality of sending the console's contents to the invoker process. I wouldn't mind seeing this feature (Output Lines in the graphical Options dialog, as well as its backing CONSOLE_CONTENTS) gone.

Expected behavior

.

Actual behavior

.

Additional context

No response

[zyv]

This is actually a very cool feature that FAR has in the Windows console. You can even adjust how much of the console is covered by the panels dynamically. I'm very much missing this in the terminal mode. Unfortunately, all we have there is Ctrl+O. But I wouldn't mind removing it from the console mode if it's broken and too hard to fix, while presenting security/privacy issues.

[egmontkob]

This is actually a very cool feature that FAR has in the Windows console.

I don't doubt that for a second!

Unfortunately, graphical terminal emulators (mostly evolved from the DEC VT series) don't allow us to implement this. We'd need a feature to copy a rectangular area from the normal screen to the alternate one, or to be able to explicitly set some cell of the alternate screen to "transparent" where the emulator displays the normal screen's contents, or something similar.

---

Or, of course, we could create a full terminal emulator... but no, let's not do that. It's an enormous amount of neverending work, necessarily coming with the limitations we already see in screen/tmux (e.g. not using the terminal emulator's native scrollback).

[egmontkob]

while presenting security/privacy issues

It's rather a potentially worrisome feature to have, I'd rather not have it. But I can't see an actual security problem with its current implementation: The permissions are thoroughly checked, and when saving the contents (that are later reported upon CONSOLE_CONTENTS) it re-checks device ownership. It's just that if you review your code and don't find a bug, it's not a guarantee :)

[zyv]

Or, of course, we could create a full terminal emulator... but no, let's not do that. It's an enormous amount of neverending work, necessarily coming with the limitations we already see in screen/tmux (e.g. not using the terminal emulator's native scrollback).

Well, this is the way that FAR took, no joke!

https://conemu.github.io

[ossilator]

Unfortunately, graphical terminal emulators (mostly evolved from the DEC VT series) don't allow us to implement this.

sure? dec vt has an escape sequence for setting the scroll area/window/margins. i don't know how thoroughly this "sandboxes" the output stream, but maybe it's good enough for implementing something that "mostly works"? i'm not saying it's worth it, though.

---

i wouldn't be so dismissive-ish of the linux console. some hardliners are using it (and even creating graphical applications for it), and i'm fairly sure that the overlap with mc users is disproportionately high.

[egmontkob]

setting the scroll area/window/margins

These are pretty weak sandboxes, it's quite easy to break out (e.g. using reset-like escape sequences). Also user-initiated window resizes reset the scroll area / margins -- mc could catch that and restore, but there'd be a race window here.

But even if you couldn't break out... you'd divide the screen in half, let's say upper half (and bottom row) is mc's, the lower half (except bottom row) is the app's. But then you couldn't Ctrl-O to see previous output, and it wouldn't make it to the scrollback buffer; everything the app outputs would stay in the bottom half and very quickly scroll out for good.

I can't foresee something better arising from it than the Ctrl-O we have on graphical (xterm-like) terminal emulators.

---

i wouldn't be so dismissive-ish of the linux console. some hardliners are using it (and even creating graphical applications for it), and i'm fairly sure that the overlap with mc users is disproportionately high.

... and those users, to a disproportionately high ratio, probably don't care about broken accented characters. I guess.

I really don't know how many such users there are. I don't want to piss them off, but I'd also see a benefit in simplifying a security-related component, and not offering any features on the VT that graphical terminals don't have.

Anyway, if there's a doubt, this feature removal can wait, we have more important things to work on.