Subshell don't save the output of the commands (ctrl+o clear the terminal)

[passat]

FreeBSD 8.2-STABLE amd64
# cd /usr/ports/misc/mc
# make && make install && make clean
# rehash
# mc -V
GNU Midnight Commander 4.7.5.5
Built with GLib 2.28.8
Using the S-Lang library with terminfo database
With builtin Editor
With subshell support as default
With support for background operations
With mouse support on xterm
With internationalization support
With multiple codepages support
Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, fish, smbfs
Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64;

Ctrl+O don't save the output of the commands in the terminal.

But in the GNU Midnight Commander 4.7.5 version it all is ok!

[angel_il]

please try 4.8.0

[fjoe]

The problem is that "ti" and "te" capabilities are missing in FreeBSD xterm (they are specified only for TERM=xterm-clear).

The "fix" is available here: ​http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/misc/mc/files/patch-lib-tty-win.c?rev=1.1;content-type=text%2Fplain

[fjoe]

The same problem exists in 4.8 branch.

[inforus]

after update to freebsd 10-stable i have the same problem.
fixed by patch:

--- lib/tty/win.c.orig  2014-09-02 13:23:58.000000000 +0400
+++ lib/tty/win.c       2014-12-02 01:37:37.000000000 +0300
@@ -95,7 +95,7 @@
 void
 do_enter_ca_mode (void)
 {
-    if (mc_global.tty.xterm_flag && smcup != NULL)
+    if (mc_global.tty.xterm_flag)
     {
         fprintf (stdout, /* ESC_STR ")0" */ ESC_STR "7" ESC_STR "[?47h");
         fflush (stdout);
@@ -107,7 +107,7 @@
 void
 do_exit_ca_mode (void)
 {
-    if (mc_global.tty.xterm_flag && rmcup != NULL)
+    if (mc_global.tty.xterm_flag)
     {
         fprintf (stdout, ESC_STR "[?47l" ESC_STR "8" ESC_STR "[m");
         fflush (stdout);

[andrew_b]

Ticket #3292 has been marked as a duplicate of this ticket.

[Zmiter]

I want to bring this problem up, since it wasn't solved yet.
FreeBSD port misc/mc includes the patch (as showed in comment 6) to solve the blank save console sreen problem, but it's a "crutch". Is there any way to solve this in mc, not the port.
I faced this problem when tried to compile mc by myself, so the patch needs to be applied by hand to everything works as expected.
If it's not forgotten, then sorry for disturb.
Thanks any way for your work. MC is the best tool.

[andrew_b]

Proposed patch

[zaytsev-work]

@Zmiter, as correctly identified by @fjoe:

The problem is that "ti" and "te" capabilities are missing in FreeBSD xterm (they are specified only for TERM=xterm-clear).

So there are 3 possibilities: (1) FreeBSD fixes xterm, (2) FreeBSD carries a patch for mc, or (3) we integrate the patch and make sure it's active only on FreeBSD (Andrew has just proposed such a patch).

I think (3) sucks most, because we have to carry a kludge and if xterm is ever fixed on FreeBSD, most likely nobody will notice that, and this patch will remain in our code forever, degrading the experience on FreeBSD.

Can you talk to the BSD maintainers to see if there is any chance to get (1) done and what their opinion on (2) & (3) is? If they are happy to carry a distro-specific patch, maybe we should just leave it this way and close this as "wontfix".

[Zmiter]

After some research I've understood the problem.
My short answer: there is nothing to do, and you can close the ticket.
And here is a more detailed answer.
'ti' and 'te' capabilities for xterm were supportted in FreeBSD some time ago. Then they desided to ammend termcap. But for those who are using these capabilities (smcup, rmcup) they made xterm-clear entry.
So, switching from 'xterm' to 'xterm-clear' make the deal and Ctrl-o saves the screen.
The patch in the port misc/mc actually corrects the problem for those who are aware of switching to 'xterm-clear' (and maybe doesn't know how to do this). It's some kind of a 'crutch'. And it's must not present in mc distro.
In my case (I'm using PuTTY for accessing the FreeBSD) the best solution is to set the name 'xterm-clear' for PuTTY configuration -> Connection -> Data -> Terminal-type string.

Some additional notes. There is one more terminal type called 'putty'. This terminal type support many of PyTTY features and so on. But this terminal type is not recognised by mc as valid xterm or console.

Another note. Terminal type 'xterm-256color' makes it's possible to use 256-color themes from mc in PuTTY console.

The last note. According to win.c in the following function we can see the mode change for saving screen.

void
do_enter_ca_mode (void)
{
    if (mc_global.tty.xterm_flag && smcup != NULL)
    {
        fprintf (stdout, /* ESC_STR ")0" */ ESC_STR "7" ESC_STR "[?47h");
        fflush (stdout);
    }
} 

But the strange thing for me is that the real sequence smcup for the terminal running mc is never sent. Instead of it mc sends the predefined sequence, which in general may not match the termcap 'te' capability.

[Zmiter]

One more question. Is there any difference in treating by mc different xterms? So, 'xterm', 'xterm-clear', 'xterm-256color', 'xterm-some-other', will their keybindings be treated different?
My question arose because of keys HOME and END stop working in panels, when I change the terminal type from 'xterm' to 'xterm-clear'. The difference between them ONLY in 'ti' and 'te' caps. All shell working is just fine - no difference. Moreover, learning of keys passes as usual and all keys are recognised.
What might be the problem is?

[andrew_b]

Replying to Zmiter:
Try add in /usr/share/mc/mc.lib:

[terminal:xterm-clear]
copy=xterm

[zaytsev]

@woodsb02, since you're our FreeBSD man, could you please chime in and express your opinion on this? Specifically, with regards to comment:8 and comment:9? Many thanks!

[Zmiter]

Replying to andrew_b:

Replying to Zmiter:
Try add in /usr/share/mc/mc.lib:

[terminal:xterm-clear]
copy=xterm

Thank you very much for your advice, everything works as expected now.
Could it be included in the next release, as 'xterm-clear' is the most 'kosher' terminal to work with mc without any additional patches?

[andrew_b]

Ticket #3659 has been marked as a duplicate of this ticket.

[andrew_b]

Ticket #3707 has been marked as a duplicate of this ticket.

[quicktrick]

On FreeBSD 11 there is another location of mc.lib: /usr/local/share/mc/mc.lib

After its editing everything works fine! Thanks a lot!

[zaytsev]

Ship xterm-clear with mclib.

[zaytsev]

So what a fun story:

• Pagers like less and editors like vi start supporting screen clearing on exit
• FreeBSD developer gets annoyed at having his screen wiped and wants to go back to the BSD roots, when these features didn't exist and/or weren't used
  • FreeBSD termcap table is patched to remove ti/te from xterm:
    • ​https://github.com/freebsd/freebsd-src/commit/9190ba057c5714e3f78bd68a62c06cc9386e3d76
  • New entry xterm-clear is created for people who are against this change
• Time passes, further developments like xterm-256colors don't take this into account
  • People work around this change around by adding ti/te to their TERMCAP variables
  • misc/mc port is patched, because the "improvement" makes it unusable
  • No attempt is ever made to revert the original "impromevent"
• At some point another FreeBSD dev tried to get a tab on the termcap & ncurses maintenance problems
  • Originally terminfo wasn't adopted to avoid political issues, but after they became irrelevant there wasn't much traction to move
  • ​https://lists.freebsd.org/pipermail/freebsd-current/2020-May/076047.html
• Current status is that terminfo is used by ncurses if misc/terminfo-db port is installed, termcap is used as fallback - maybe even termcap will be removed one day, who knows
  • ​https://github.com/freebsd/freebsd-src/commit/61f66a1f4403fded9aae14d890ad96914a3c0bc1
  • From that point on, the original behaviour is (partially) restored, and people jubilate on reddit and forums, not knowing where the blessing came from
    • ​https://www.reddit.com/r/freebsd/comments/1dxd7bm/term_alternate_screen_buffer_xterm256color/
    • ​https://forums.freebsd.org/threads/behavior-change-in-term-after-freebsd-14-1-update.94022/
• The history continues... what's next? Will terminfo eventually be "improved" in the same way as termcap? Or will termcap finally be removed and the original terminfo prevail? We will find out in the next 20 years.

[zaytsev]

Branch: 2633_mclib_xterm_clear
Changeset: f0107ce193a4cfc983c2034dd739d972645dbb98