伪 TTY 行限制为 256 个字符？
使用 Plink (PuTTY) 从 Windows 计算机到 Solaris 服务器打开 SSH 连接，方法是：
Plink.exe -t <hostname> /bin/bash
然后将 bash 命令行写入 Plink.exe 的 stdin，并由远程 /bin/bash/bin/bash 过程。
只要 bash 命令行不超过 256 个字符，它就可以工作。写入 256 个字符后，不再回显任何字符，而是为每个附加字符返回一个 BEEP（ASCII 代码 7）。
（使用 /bin/bash 而不是直接调用脚本可能看起来很奇怪，但这是更复杂场景的简化示例）
256 个字符的限制似乎仅在 -t使用标志，但在 Solaris 服务器上执行的命令需要 TTY。
Plink.exe 进程是从 Windows 计算机上的 JVM 启动的。
我尝试使用 PuTTY 会话配置加载 Plink.exe，并关闭“本地行编辑”和“本地回显”，但行为是相同的。
256 个字符的限制是在 SSH 客户端 (Plink.exe) 中还是在服务器端（Solaris、OpenSSH、Bash）？
如何避免 256 个字符的限制？
A SSH connection is opened with Plink (PuTTY) from a windows machine to a solaris server via:
Plink.exe -t <hostname> /bin/bash
Then a bash command line is written to stdin of Plink.exe and is parsed and executed by the remote /bin/bash process.
It is working as long as the bash command line is no longer than about 256 characters. After 256 characters have been written, no more characters are echoed back and instead a BEEP (ASCII code 7) is returned for each additional character.
(It may seem strange to use /bin/bash instead of calling a script directly, but this is a simplified example of a more complex scenario)
The 256 character limit does only seem to occur if the -t flag is used, but the commands that are executed on the solaris server require a TTY.
The Plink.exe process is started from a JVM on the windows machine.
I tried loading Plink.exe with a PuTTY session configuration with "Local line editing" and "Local echo" both turned off, but the behavior was the same.
Is the limitation of 256 characters in the SSH client (Plink.exe) or on the server side (Solaris, OpenSSH, Bash)?
How can the 256 character limitation be avoided?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
规范模式下 TTY 的输入是逐行读取的，非常大的行可能无法放入输入队列。通过将 TTY 设置为原始模式，可以直接读取每个字符，并且行数可以大于输入队列。
通过调用“stty raw”解决了该问题。
Input to a TTY in canonical mode are read line by line, and a very large line may not fit into the input queue. By setting the TTY in raw mode, each character can be read directly and lines can be larger than the input queue.
The problem was solved by calling: "stty raw".