主页 / unix / 问题 / 788569
Accepted
elbarna
Asked: 2024-12-23 16:11:19 +0800 CST

为什么我的 Solaris 终端被“截断”了？

  • 772

奇怪的情况

在 Linux 上，我的终端工作正常，在此示例中，在 man wget 之后...

在此处输入图片描述

在 Solaris 10 上...

##图片从这里开始##

在此处输入图片描述

##图片到此结束##

如您所见，当出现 root@solaris10 时，输出在中间被截断。

这是我在 Linux 上的终端设置

stty -g
4500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Solaris 上的 stty -g

500:5:f00bf:8a3b:3:1c:7f:15:4:0:0:0:11:13:1a:19:12:f:17:16:0:0:1:1:0:00:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0

Linux 上更友好的输出 stty -a

speed 38400 baud; rows 24; columns 120; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q;
stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

这是在 Solaris 上

speed 38400 baud; 
rows = 24; columns = 120; ypixels = 0; xpixels = 0;
csdata ?
eucw 1:0:0:0, scrw 1:0:0:0
intr = ^c; quit = ^\; erase = ^?; kill = ^u;
eof = ^d; eol = <undef>; eol2 = <undef>; swtch = <undef>;
start = ^q; stop = ^s; susp = ^z; dsusp = ^y;
rprnt = ^r; flush = ^o; werase = ^w; lnext = ^v;
-parenb -parodd cs8 -cstopb -hupcl cread -clocal -loblk -crtscts -crtsxoff -parext 
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc 
ixon -ixany -ixoff -imaxbel 
isig icanon -xcase echo echoe echok -echonl -noflsh 
-tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten 
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel

使用的术语，在 Linux 和 Solaris 上都是 xterm，我在 Solaris 上使用 TERM=dtterm 进行更改，但没有任何变化。

此gif显示了 Solaris 上使用 vim 时发生的情况

EDIT1：重置终端后，Solaris 终端也恢复正常，但使用一段时间后又会出现问题，所以这不是解决方案。

EDIT2：发生在 ssh 终端上，在控制台终端上运行良好。

terminal

2 个回答

  1. Best Answer

    在这两个系统上，stty -a信息都表明终端窗口的大小应为 120x24 个字符（rows 24; columns 120在 Linux 和 上rows = 24; columns = 120）。在您的 Linux 屏幕截图上，这似乎是事实。但在您的 Solaris 屏幕截图中，显然有超过 24 行，stty -a当时的输出应该反映这一事实。Solaris 输出似乎在第 24 行之后被截断，因此 shell 和您正在运行的任何其他程序都只是将 指示的终端大小stty -a作为绝对事实。

    当您调整终端窗口大小时，终端仿真器进程（例如，xterm在您的情况下）应该SIGWINCH向在该终端窗口内运行的进程发送窗口更改信号（ ），以告知它们窗口大小已更改。然后，进程应该更新设置stty及其对显示大小的内部概念。

    当远程终端连接和旧的商业 Unix 软件等复杂因素加入进来时，有时可能会发生信号无法传送，或者仅传送给当时在终端上处于活动状态的进程的情况。

    因此，当您连接到远程主机、登录、启动文本编辑器，然后调整窗口大小以更好地查看您正在编辑的内容时，编辑器可能会收到窗口大小已更改并进行调整的消息...但是一旦您退出编辑器并启动其他程序，例如man，您可能会看到 shell 没有收到 SIGWINCH，并且在信息stty和/或COLUMNS环境LINES变量中仍然有错误的窗口大小信息...并且由于 shell 的环境变量由其子进程继承，因此 shell 现在正在传播有关窗口大小的不正确信息。

    是的，解决这个问题的正确方法是确保所有相关程序正确处理 SIGWINCH 和终端大小变化……但不幸的是，旧的缺陷软件似乎永远不会完全消失。

    通常的解决方法是退出出现错误行为的全屏程序，然后eval $(resize)在启动它的 shell 中运行（或等效运行）。它应该重新探测当前窗口大小并调整信息stty和上述环境变量以匹配实际窗口大小。换句话说，它会手动强制执行本应由于 SIGWINCH 而自动发生的事情。

    有时简单的resize就足够了；但是使用该eval $(resize)形式也会导致 shellCOLUMNS和LINES环境变量被更新……有时您会使用一些使用这些环境变量中的值并期望它们是正确的旧软件。

    此后，最好记住这样的话：“我处于一个对 SIGWINCH 处理不太完美的系统中；最好只在终端上只有 shell 提示符时才调整终端窗口大小，而不是在运行某些全屏程序时调整。”

    （我似乎记得旧的 Solaris 版本曾经有相当旧的vi和默认实现more...而后者可能也被和类似程序用作默认分页器man。如果它们的 SIGWINCH 处理不够完美，我不会太感到惊讶。）

    • 1

  2. 找到解决方案。根据用户建议，这种情况发生在 ssh 上，我尝试了

    ssh -t solaris10

    看起来工作正常。

    • 0

相关问题