On 24-Aug-2012, Mike Miller wrote:
| On Fri, Aug 24, 2012 at 11:56 AM, John W. Eaton wrote:
| > On 24-Aug-2012, Mike Miller wrote:
| >
| > | More on-topic, I tested running the GUI from a launcher and it still
| > | has some quirks with the pager and info browser, which I think are all
| > | due to qterminal not setting TERM to declare its terminal
| > | capabilities. Once I setenv("TERM", "xterm") everything looks alright.
| > | I'll report that separately.
| >
| > It seems like that should be handled by having qterminal select some
| > reasonably feature rich default TERM type if none is specified in the
| > environment. I'm not sure what default it uses now when TERM is not
| > set in the environment.
|
| Exactly, except strike out "if none is specified in the environment".
| It looks like it's emulating "vt102/xterm" from some quick grepping,
| but I haven't looked into it too deeply. If TERM is unset, it's
| currently unset in Octave. Qterminal is its own terminal emulator so
| only it can say what its terminal type is, right? Doesn't matter what
| the terminal mode of the parent process was.
Qterminal does appear to behave differently depending on what the
value of TERM is when it starts. For example, try
TERM=vt102 ./run-octave
vs.
TERM=dumb ./run-octave
I have no idea why it would need to do that. It seems overly complex
for it to try to emulate multiple terminal types. It seems to me that
one relatively common feature rich terminal would be sufficient, and
that it should simply always behave that way. But maybe I'm missing
some reasonable justification for providing multiple terminal
personalities.
What do you mean with "behave differently". It's possible that it's the actual software running within the terminal is behaving differently, not QTerminal. For instance, readline library will behave differently based on the terminal it's running in. The problem is maybe more that QTerminal should redefine the TERM variable to match its own emulation.
Michael.