Xterm 终端和调整代码大小
我正在转换一个 25 年前的非常旧的应用程序。
它发送一个转义序列以使 SCREEN 132 个字符宽...
然而它没有工作，我把 XTERM 等价物放在大多数情况下似乎工作。
虽然
"\x1B[8;50;132t"
屏幕大小成功调整，但有一个问题 执行命令的代码
pg -f FILETOSHOW
以下是 COBOL 程序使用 CALL "SYSTEM" USING BY CONTENT DS-REC
其中 DS-REC 是上面的命令....
问题是，虽然屏幕调整大小数据是使用以前的设置打印的...再次调用程序解决了问题并正确打印...
没有人知道我是否还应该发送另一个转义码？
I am in progress of converting a really old 25+ year old application .
It sends an escape sequence to make the SCREEN 132 characters wide...
However it didnt work and i put the XTERM equilivment that seems to work in most cases..
It is
"\x1B[8;50;132t"
Although the screen resizes with success there is an issue
Here is the code that the COBOL program uses to execute the command
pg -f FILETOSHOW
using CALL "SYSTEM" USING BY CONTENT DS-REC
where DS-REC is the above command....
The problem is that although screen resizes data are printed with the previous settings... Calling again the program solves the issue and prints correctly...
Doesnt anybody knows whether i should send another escape code also?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
转义序列记录在 XTerm 控制序列中，位于“使用 CSI 的函数，按最终字符排序" 部分，在此行下：
它是改编自 dtterm，特别是
它于 1996 年在 xterm 中实现（补丁 #18）。
由于某些用户将此类操作视为安全问题（包括调整字体大小），因此在 2003 年添加了资源
windowOps(补丁#174）以允许打包者更改默认行为。该资源可以在运行时使用菜单项进行修改，也可以直接在用户的 X 资源中设置。简而言之，该功能存在于 xterm 中，但可能需要（简单的）配置更改才能使用它。
调整 xterm 窗口大小的控制序列是对窗口管理器的请求。窗口管理器可能不会接受该请求，例如，对于平铺窗口管理器，它总是会失败。另外，由于 xterm 不会动态更改字体大小，因此如果字体大小太大而无法在屏幕上显示 132 列，则可能会失败。
fixed字体可能适用于现代大型显示器（我的 1280x1024 显示器可以显示 60x210，但有一些松弛），但大字体可能不适用于。当它无法按照请求调整大小时，窗口管理器将处理该请求：当请求完成时，xterm 已经忘记了，并且将接受窗口管理器所做的任何操作。
The escape sequence is documented in XTerm Control Sequences, in the "Functions using CSI , ordered by the final character(s)" section, under this line:
It is one of the controls adapted from dtterm, and in particular
It was implemented in xterm in 1996 (patch #18).
Because some users view operations of this sort as a security problem (including resizing the font), a resource
windowOpswas added in 2003 (patch #174) to allow packagers to change the default behavior. That resource can be modified at runtime using a menu entry, as well as set directly in a user's X resources.In short, the feature is present in xterm, but may require (simple) configuration changes to use it.
The control sequence to resize the xterm window is a request to the window manager. The window manager may not honor the request, e.g., for tiling window managers it would always fail. Also, because xterm does not change the font-size dynamically, it may fail if the font size is too large to permit 132 columns on the screen. The
fixedfont probably works for modern large displays (my 1280x1024 monitor can display 60x210 with some slack), but large fonts may not.When it fails to resize as large as requested, it is the window manager which handles the request: xterm has forgotten by the time the request is completed, and will accept whatever the window manager does.
不要依赖这些转义码。 xterm 不会将自身设置为大于屏幕的尺寸。因此，如果用户拥有足够大的字体和/或足够小的屏幕，他将不会自动获得 132x50 的终端，更不用说自动调整大小了。
（例如，lucida 控制台在 1024x600 上的 15pt 减去任务栏，而 WM deco 为我提供了 85x28 单元格的空间。）
如果您的程序需要 132x50 这样一个尴尬的 vt 大小，请向用户请求它作为先决条件。或者只是让你的程序实际运行在任何可变大小上。
Do not rely on these escape codes. xterm will not set itself to a size greater than the screen. So given the user has a large-enough font and/or a small-enough screen, he will not get his 132x50 terminal automatically, much less will the automatic sizing do it.
(E.g. lucida console at 15pt on 1024x600 minus a taskbar and WM deco gives me room for 85x28 cells.)
If your program requires such an awkward vt size of 132x50, request it of the user as a prerequisite. Or just make your program actually run on any variable size.