[solved] Tektronix mode in xterm. Possible bug?

[angros47]

I tried to run a program compiled in freebasic from xterm: in normal mode, it works perfectly, but in tek mode (to select it, you need to press ctrl+middle mouse button, and select "Switch to Tek mode"), if I try to launch a program written in FB the terminal hangs, writing "?1h6n", until I press ctrl+break. It happens both in 32 and 64 bit linux, both with asm and gcc emitter.

Programs compiled with c work perfectly under Tek console. Does anyone have an idea of why this happens?

(I was trying to run a program like this one: https://youtu.be/T-F7ZySfgZ0?t=110 )

[caseih]

As always, a short, run-able snippet of code that exhibits the problem is helpful.

[angros47]

Actually any code (even a simple "hello world" example) causes the problem. Even invoking the compiler itself from xterm in Tek mode gives the error.

[caseih]

Doing a bit of tracing here. I don't think this is an FB bug per se. FB is just trying to control the terminal as best it knows how, according to the TERMINFO database. Somehow some of the escape codes FB is outputting, or maybe the ioctls() it is calling on the terminal are not returning in tektronix mode.

[dkl]

Yea, FB currently requires the terminal to support certain ANSI escape sequences (especially the cursor position query \e[6n). It's a problem if the terminal doesn't send responses to the program (currently FB just hangs in that case).

However, in recent FB versions there is a way to disable some of these internals: examples/console/disable-vt100-escapes.bas
It's possible that this works in your case.

[angros47]

Actually, if "trying to control" means crashing the terminal, it is a bug. In theory, a bare bone FreeBasic program should not send any escape code to the terminal (and, if I redirect its output to hexdump, for example, it shows no output). If I redirect the output to /dev/null, it seems to work without crashing.

With the last version, disabling the escapes, it seems to work, although it still emits some garbage, like "?1h" before the output, and "0m?12l?25h?1l" at the end.

[caseih]

Your initial report said nothing about crashing the terminal. Definitely doesn't crash the terminal for me. And if it could crash the terminal, that is a bug, but not in FB; it'd be an xterm bug. No external input should cause a program to crash.

I'm sure FB and FB's runtime could be smarter about terminal handling, but properly running on an an ancient Tektronix terminal has to be low on the list of priorities for feature enhancements and bug fixing! Sorry that you've run into it, though and that it caused you grief. In 20 years of using Linux, you're the only person I've ever heard of who used the Tektronix emulation in xterm. Sounds like a fun relic to play with.

EDIT: Disregard this next paragraph... FB already turns off terminal control codes when there's no controlling pty, such as if you would pipe output.
The problem with the idea that FB should emit no codes at all is that you'd have to have two paths of execution throughout the runtime. One where commands like color, locate, etc are not available, and even commands like input would have reduced functionality (no cursor movement, no line editing). Then you'd need the full-featured mode that's still text mode, but with all the codes. FB was designed originally it be compatible with QB in all its glory, including a full-featured and colorful text mode, which is faithfully emulated on a terminal. For most purposes this is the right thing to do I think.

[marcov]

Actually, if "trying to control" means crashing the terminal, it is a bug.

Or somebody doing palaeontology

[angros47]

I know that mine is just computer palaeontology, but GCC allows me to do that. I just wanted to know why FB didn't, and if it could be an issue on other situations, too. Basically, dkl answered my question. And I guess that I am not the only one to have noticed the potential problems with that, since a way to disable escape codes has been provided in the last version.

I know that this is a low priority issue, but why not reporting it anyway? There was a solution, after all, that I didn't know about (disabling escape sequences), so I learnt something.

[caseih]

Yes that's true. I was mistaken in what I said earlier; not sure what I was thinking. In fact if you want to create any kind of program that takes standard in, does something, and then outputs to standard out for use in chaining pipes together, you normally don't want codes. And in fact, when the FB runtime detects no pty (such as a pipe), it turns off codes. So you might be able to get your FB code to work with the Tektronix terminal simply by doing:

Code: Select all

$ ./myfbprog | cat