The pop-up window for format information is incorrect when compared to
functionality and the documentation at
qdn.qnx.com/support/docs/neutrino_qrp/utilities/p/pterm.html
This document, however, does not mention %$ which shows the process id, it
seems.
%a (and as a result, %A) fails to properly display argv[1] in at least two
ways:
- no space exists between argv[1] and argv[2]
- all string processing stops if a “@” character is seen.
Examples:
if I run “ssh login@somewhere.net command-to-run command-args” in pterm, and
my title is “%A” (or “%0 %a”), the displayed title is:
ssh logincommand-to-run command-args
instead of
ssh login@somewhere.net command-to-run command-args
argv[2] and beyond do not have the “@” problem.
Kees Cook <cook@cpoint.net> wrote:
The pop-up window for format information is incorrect when compared to
functionality and the documentation at
qdn.qnx.com/support/docs/neutrino_qrp/utilities/p/pterm.html
This document, however, does not mention %$ which shows the process id, it
seems.
Also, it does mention %t, which isn’t supported under Neutrino. I’ll
let the docs people know. Thanks.
%a (and as a result, %A) fails to properly display argv[1] in at least two
ways:
- no space exists between argv[1] and argv[2]
That’s true. I have just fixed this. Thanks.
- all string processing stops if a “@” character is seen.
I don’t think the problem is that general. I just ran “tee a@b@c def”
in a pterm, and the %A said “tee a@b@cdef” (because of the other bug).
Examples:
if I run “ssh > login@somewhere.net > command-to-run command-args” in pterm, and
my title is “%A” (or “%0 %a”), the displayed title is:
ssh logincommand-to-run command-args
My guess is that ssh modifies its argument list. Unfortunately, I don’t
think there is a way for pterm to find out what the argumets really were
before they got modified…
\
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.
Wojtek Lerch wrote in message <98r57g$j5o$1@nntp.qnx.com>…
- no space exists between argv[1] and argv[2]
That’s true. I have just fixed this. Thanks.
Great!
I don’t think the problem is that general. I just ran “tee a@b@c def”
in a pterm, and the %A said “tee a@b@cdef” (because of the other bug).
Ya know, I thought I had tested that case, but that must have been when I
noticed the difference in the documentation and I got myself confused.
My guess is that ssh modifies its argument list. Unfortunately, I don’t
think there is a way for pterm to find out what the argumets really were
before they got modified…
You’re absolutely right. I just verified this with “ps”. How odd. (And to
think, all I wanted was a way to see the host name I had ssh’d to.)
Another question: in the xterm (or VT100? ANSI?) spec, there is an escape
code:
\033]0;TEXT\007
(\033 == ESC, \007 == BELL) that lets you change the window title for your
terminal. This is, for example, supported by “xterm”, and even most other
terminal programs (NCSA telnet, even). Could this be supported by pterm as
well?
Kees Cook <cook@cpoint.net> wrote:
…
Another question: in the xterm (or VT100? ANSI?) spec, there is an escape
code:
\033]0;TEXT\007
(\033 == ESC, \007 == BELL) that lets you change the window title for your
terminal. This is, for example, supported by “xterm”, and even most other
terminal programs (NCSA telnet, even). Could this be supported by pterm as
well?
Pterm has a similar escape sequence already:
‘t’
where is either character 9D or ‘]’, and is either 9C
hex or ‘’.
BTW According to my copy of ISO/IEC 6429, the escape sequence that xterm
uses is broken. According to that standard, a control string introduced
by must be terminated by and is not allowed to contain the
BEL character or most other control characters.
–
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.