abc at ai1.anchorage.mtaonline.net
abc at ai1.anchorage.mtaonline.net
Tue Jul 1 19:43:18 PDT 2003
Questions regarding FreeBSD should be addressed to the FreeBSD
Questions mailing list, freebsd-questions at 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
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.
> > 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.
More information about the freebsd-questions