Date: Wed, 2 Jul 2003 02:43:18 GMT From: abc@ai1.anchorage.mtaonline.net To: Kris Kennaway <kris@obsecurity.org>, Malcolm Kay <malcolm.kay@internode.on.net> Cc: freebsd-questions <questions@freebsd.org> Subject: Re: vt/ansi codes Message-ID: <200307020243.h622hIuP079791@en26.ai1.anchorage.mtaonline.net>
next in thread | raw e-mail | index | archive | help
http://www.freebsd.org/mailto.html Questions regarding FreeBSD should be addressed to the FreeBSD Questions mailing list, freebsd-questions@FreeBSD.ORG. Mailing lists are the primary support channel for FreeBSD users, with numerous mailing lists covering different topic areas. Several non-English mailing lists are also available. the basis for this question was to determine if it was feasible to write a portable FBSD application and/or library without external dependencies. it is understood what "ncurses" and "SLang" are for - and initially ANSI escape sequences seemed to provide a way to break through the burdens and complications of ncurses and termcap entries. and in learning a bit about terminal I/O, "questions regarding FreeBSD" came to mind. -- the way things are, based on pcvt(4) and xterm(1), is that FreeBSD (and XFree86) implements vt220 (and vt102) "emulation" as the main terminal I/O driver. i fail to see the intelligence of implementing terminal drivers that are based upon 25 year old antiquated commercial terminals and their associated proprietary and "deficient" command sets, thereby forcing the use of special library dependencies containing various optimization hacks to work around such deficiencies. wouldn't it be much more intelligent/efficient/effective to implement non-commercial "universal" escape sequence standards that are more functional (such as 1979 ANSI 3.64) thereby eliminating the need for special library dependencies with regard to terminal I/O apps; reserving such library dependency usage for terminals that need such hacks due to their proprietary/limited command sets? i mean - why "dumb down" FBSD on a PC to the level of a antiquated proprietary terminal command set, and ineffectively force the use of oft broken inefficient hacks in library dependencies to make up for the deficiencies? why not "smarten" FBSD (and XFree86/xterm) terminal I/O to use more "universal" escape sequence standards that take better advantage of PC capabilities, and relegate usage of ncurses/termcap and the like to those programs requiring specialized hacks to run on proprietary hardware/terminals? why not shift the focus of terminal I/O to better suited "universal" standards, instead of a 25 year old proprietary and limited command sets. i think this would result in much greater all-around productivity. Chris > > i am trying to develop terminal I/O based code, > > and found myself meandering down a path > > to acquire terminal knowledge (i don't > > need to be told of SLang/ncurses/...). > I wonder with this is really relavent to FreeBSD questions. But in any case > here is my 2 cents worth. Have you looked at termcap and terminfo, which of > course underpin curses/ncurses. It doesn't really matter what standards > might be defined; the important issue is what functions commonly available > terminals and terminal emulations have. There are an enormous variety of > terminals and terminal emulations which have very little in the way of a > common subset of functions. If you must use one common subset then you had > best stick to VT100, I guess that will get you into between 1/3 and 2/3 of > the terminals and emulations out there. Unix and same other OS have dealt > with the problem by using databases of terminal information - termcap and/or > terminfo - so that terminals with different control sequences can be managed > by the same software and the software doesn't need prior knowledge of the > specific control codes. In 1979 to send a full screen of say 2000 characters > took perhaps 1 to 5 minutes, now in a similar situation we commonly send > that in 20 to 100 milliseconds so the problem of dealing with different > standards is largely circumvented by using less in the way of fancy > functions and instead just redrawing the screen. Now-a-days graphic displays > generally get more attention (not that I think this is necessarily good) and > means of updating these with respect to the available bandwidth is receiving > considerable attention. > > Malcolm Kay > UNIX is designed not to rely on one single terminal type. IMO, tailoring > writing your application so it can only run on vt100 terminals (or ansi > terminals, if you had your wish) is misguided..use one of the character > display libraries that handle all the internal details in a > terminal-independent way. > > Kris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307020243.h622hIuP079791>