-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Micah Cowan wrote: > Andrew McGill wrote: >> On Monday 28 July 2008 21:28:07 Micah Cowan wrote: >> ... >>>> A neat place for timing information is to define a "delay in input" >>>> escape - e.g. a delay of 1.123456 seconds is represented by ESC [ 42 ; 1 >>>> ; 123456 ] (with a meta-meaning of "life is full of short delays") >>> Esc [ ... ] is SDS, and is supposed to be the _start_ of a longer >>> control string (with support for nesting). Probably a poor choice of >>> escape. >> There is already a conflict between the Linux console escapes and ECMA 48's >> SDS. (And do we really like ECMA?) > >> QOTD >> >> Sequence: CSI Ps ; Pn ... ] >> Description: Linux private sequences > >> ESC [ 1 ; n ] Set color n as the underline color >> ESC [ 2 ; n ] Set color n as the dim color >> ESC [ 8 ] Make the current color pair the default attributes. >> ESC [ 9 ; n ] Set screen blank timeout to n minutes. >> ESC [ 10 ; n ] Set bell frequency in Hz. >> ESC [ 11 ; n ] Set bell duration in msec. >> ESC [ 12 ; n ] Bring specified console to the front. >> ESC [ 13 ] Unblank the screen. >> ESC [ 14 ; n ] Set the VESA powerdown interval in minutes. > >> Source: Linux console_codes(4) >> Status: Linux private; clashes with ECMA-48 SDS >> <<QOTD > > That's well and good, but what about other terminals that may actually > understand SDS, and stop rendering characters until it sees the > terminating SDS? Just because one terminal does it doesn't mean we > should follow suit. Since "we" are on vger.kernel.org, perhaps this was a little bit of a funky thing to say. However, script is intended to work with a large variety of terminals, so it still seems to me that we'd want a different approach than the one taken for the linux terminal: we want a sequence that's maximally portable with other terms; I doubt this one is. OTOH, maybe we won't find a really portable sequence. In that case, there's perhaps nothing wrong with saying "you must feed this back to scriptreplay; don't cat it out directly." As I mentioned before, though, my priority is in fixing the existing mechanism - or at least making its interpretation consistent between script and scriptreplay. If I want editable timing, I already have my Teseq program ;) One advantage the current two-files solution has is smaller processing overhead (probably not significantly, though). A script that has to process special escape sequences has to examine the typescript data being read, and maintain state. The current solution is a dead-simple "process delay; read N bytes; write N bytes". There's never a question of when it will find the next delay, it's ready at the next timing-file read. (However, I don't consider that slight shortcoming to compensate for the disadvantages of the current system.) > That's what intermediate bytes are for. Since there's an infinite > combination of intermediate-bytes + private final bytes, that really is > all one should need. \[[Pm~ taken? Try \[[Pm!~ or \[[Pm$~ or \[[Pm$!+,/~... Except, of course, apparently some terminals don't respect these (vte, for one). :\ Still, perhaps we could use control strings appropriately, rather than embedding it in a start-of-control-string delimiter. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer, and GNU Wget Project Maintainer. http://micah.cowan.name/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIjjnJ7M8hyUobTrERAl2KAJ4rJUdHmdxllDEV+AkJ47wrwqRX+wCeIHNU LuigouNTY3olRwRV7g/Oyvo= =YRmD -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
