> > It doesn't and thus signals the emulator to by-pass the normal parser
> Definitly not. The VT100 emulation contains CSI ? 26 n, CSI > c and
> several other sets, the SCO ANSI emulation contins a load of CSI = ...
> sequences. They all follow 5.4.2.
Not to mention that there is no requirement that there be only a
single 'private' byte. Other terminals use
CSI = ? Pn I
CSI ? = Pn I
CSI ? = l
CSI = ? l
CSI ? = m
CSI = ? m
CSI = ? Pn J
CSI = ? Pn J
> > > The normal way to implement a special string is with a DCS code eg..
> > >
> > > ESC P w (*$&%(*^$(%<>?:@~@!"~# ST
> >
> > I doubt, existing terminal emulators (counting only those with less
> > brain damaged control function parsers than the sad Linux console) would
> > ignore such a sequence properly if unknown, whereas they would ignore
> > mine as it is within the normal syntax. You could bracket the string
> They _might_ ignore it, as you probably tested neither the Linux console
> nor current (I tried XF86 3.3.6) xterm versions ignore it. The only ones
> that I found quickly were a real WY120 terminal and PuTTY.
> (PS: Jeffrey, I didn't try kermit ...)
Kermit will ignore a DCS sequence it does not recognize. I currently
support the VT DCS commands:
DECUDK, DECRSPS, DECRQSS
and ignore others that are unknown.
> > Using the plain normal command syntax where the parameter string is
> > restricted to the third ASCII column (0-?) seems much safer to me,
> > because any other character will terminate or abort the control
> > sequence, which sounds less accident prone than having to wait on one
> > particular C1 STRING TERMINATOR byte (what if that got corrupted?).
> > My SCW proposal gets aborted by the next LF, which makes it rather safe
> > as the effect is restricted to a single line (except for the ":" and ";"
> > bits, which I said is more for discussion and I don't mind if you prefer
> > not to implement it). The aborting property of LF holds for both the
> > sequence itself as well as for the sequence of affected graphic
> NO NO! This is a VERY common mistake! Embedded control characters do
> NOT abort CSI sequences. ECMA-48 highlights the SO and SI characters
> but a VT emulation must allow everything except ESC and CAN which have
> specifically defined effects.
The only control characters that terminate the processing of an ESC or
CSI are CAN and SUB. CAN resets the parser and destroys the contents
of the buffer. SUB resets the parser but outputs the contents of the
buffer to the display device. Other characters that affect the parser
buffer are BS (erase previous character); ESC (restarts a new ESC
sequence forgetting the one in progress); CSI (restarts a new CSI
sequence forgetting the one in progress).
Every other control character is passed through to the display device
and is process immediately without regard to the contents of the
parser. In other words,
CSI ? LF 6 n
results in
CSI ?
process line feed (scroll terminal or wrap to top if necessary)
6 n
process DECXCPR and respond with the new cursor position.
> There's also a very good chance that the terminal already has either
> DCS sequences (ReGIS/Sixel graphics, VT220 reports, VT400 macros) or
> other ST terminated sequences (sysline, window/icon title) so another
> one isn't going to make a difference.
And at the very least the terminal must swallow the contents of the
DCS,APC,OSC,PU1,PU2,... sequences if they are not recognized.
Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available
The Kermit Project @ Columbia University includes Secure Telnet and FTP
http://www.kermit-project.org/ using Kerberos, SRP, and
[EMAIL PROTECTED] OpenSSL. SSH soon to follow.
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
