hackguide.html

ncurses 库 可能有用酒用 没用就算了 我觉得还可以用

handle termcap syntax and compile that too into terminfo entries. <P>

The implementation therefore starts with a table-driven, dual-mode
lexical analyzer (in <CODE>comp_scan.c</CODE>).  The lexer chooses its
mode (termcap or terminfo) based on the first `,' or `:' it finds in
each entry.  The lexer does all the work of recognizing capability
names and values; the grammar above it is trivial, just "parse entries
till you run out of file".

<H2><A NAME="nonuse">Translation of Non-<STRONG>use</STRONG> Capabilities</A></H2>

Translation of most things besides <STRONG>use</STRONG> capabilities is pretty
straightforward.  The lexical analyzer's tokenizer hands each capability
name to a hash function, which drives a table lookup.  The table entry
yields an index which is used to look up the token type in another table,
and controls interpretation of the value. <P>

One possibly interesting aspect of the implementation is the way the
compiler tables are initialized.  All the tables are generated by various
awk/sed/sh scripts from a master table <CODE>include/Caps</CODE>; these
scripts actually write C initializers which are linked to the compiler.
Furthermore, the hash table is generated in the same way, so it doesn't
have to be generated at compiler startup time (another benefit of this
organization is that the hash table can be in shareable text space). <P>

Thus, adding a new capability is usually pretty trivial, just a matter
of adding one line to the <CODE>include/Caps</CODE> file.  We'll have more
to say about this in the section on <A HREF="#translation">Source-Form
Translation</A>.

<H2><A NAME="uses">Use Capability Resolution</A></H2>

The background problem that makes <STRONG>tic</STRONG> tricky isn't the capability
translation itself, it's the resolution of <STRONG>use</STRONG> capabilities.  Older
versions would not handle forward <STRONG>use</STRONG> references for this reason
(that is, a using terminal always had to follow its use target in the
source file).  By doing this, they got away with a simple implementation
tactic; compile everything as it blows by, then resolve uses from compiled
entries. <P>

This won't do for <STRONG>ncurses</STRONG>.  The problem is that that the whole
compilation process has to be embeddable in the <STRONG>ncurses</STRONG> library
so that it can be called by the startup code to translate termcap
entries on the fly.  The embedded version can't go promiscuously writing
everything it translates out to disk -- for one thing, it will typically
be running with non-root permissions. <P>

So our <STRONG>tic</STRONG> is designed to parse an entire terminfo file into a
doubly-linked circular list of entry structures in-core, and then do
<STRONG>use</STRONG> resolution in-memory before writing everything out.  This
design has other advantages: it makes forward and back use-references
equally easy (so we get the latter for free), and it makes checking for
name collisions before they're written out easy to do. <P>

And this is exactly how the embedded version works.  But the stand-alone
user-accessible version of <STRONG>tic</STRONG> partly reverts to the historical
strategy; it writes to disk (not keeping in core) any entry with no
<STRONG>use</STRONG> references. <P>

This is strictly a core-economy kluge, implemented because the
terminfo master file is large enough that some core-poor systems swap
like crazy when you compile it all in memory...there have been reports of
this process taking <STRONG>three hours</STRONG>, rather than the twenty seconds
or less typical on the author's development box. <P>

So.  The executable <STRONG>tic</STRONG> passes the entry-parser a hook that
<EM>immediately</EM> writes out the referenced entry if it has no use
capabilities.  The compiler main loop refrains from adding the entry
to the in-core list when this hook fires.  If some other entry later
needs to reference an entry that got written immediately, that's OK;
the resolution code will fetch it off disk when it can't find it in
core. <P>

Name collisions will still be detected, just not as cleanly.  The
<CODE>write_entry()</CODE> code complains before overwriting an entry that
postdates the time of <STRONG>tic</STRONG>'s first call to
<CODE>write_entry()</CODE>, Thus it will complain about overwriting
entries newly made during the <STRONG>tic</STRONG> run, but not about
overwriting ones that predate it.

<H2><A NAME="translation">Source-Form Translation</A></H2>

Another use of <STRONG>tic</STRONG> is to do source translation between various termcap
and terminfo formats.  There are more variants out there than you might
think; the ones we know about are described in the <STRONG>captoinfo(1)</STRONG>
manual page. <P>

The translation output code (<CODE>dump_entry()</CODE> in
<CODE>ncurses/dump_entry.c</CODE>) is shared with the <STRONG>infocmp(1)</STRONG>
utility.  It takes the same internal representation used to generate
the binary form and dumps it to standard output in a specified
format. <P>

The <CODE>include/Caps</CODE> file has a header comment describing ways you
can specify source translations for nonstandard capabilities just by
altering the master table.  It's possible to set up capability aliasing
or tell the compiler to plain ignore a given capability without writing
any C code at all. <P>

For circumstances where you need to do algorithmic translation, there
are functions in <CODE>parse_entry.c</CODE> called after the parse of each
entry that are specifically intended to encapsulate such
translations.  This, for example, is where the AIX <STRONG>box1</STRONG> capability
get translated to an <STRONG>acsc</STRONG> string.

<H1><A NAME="utils">Other Utilities</A></H1>

The <STRONG>infocmp</STRONG> utility is just a wrapper around the same
entry-dumping code used by <STRONG>tic</STRONG> for source translation.  Perhaps
the one interesting aspect of the code is the use of a predicate
function passed in to <CODE>dump_entry()</CODE> to control which
capabilities are dumped.  This is necessary in order to handle both
the ordinary De-compilation case and entry difference reporting. <P>

The <STRONG>tput</STRONG> and <STRONG>clear</STRONG> utilities just do an entry load
followed by a <CODE>tputs()</CODE> of a selected capability.

<H1><A NAME="style">Style Tips for Developers</A></H1>

See the TO-DO file in the top-level directory of the source distribution
for additions that would be particularly useful. <P>

The prefix <CODE>_nc_</CODE> should be used on library public functions that are
not part of the curses API in order to prevent pollution of the
application namespace.

If you have to add to or modify the function prototypes in curses.h.in,
read ncurses/MKlib_gen.sh first so you can avoid breaking XSI conformance.

Please join the ncurses mailing list.  See the INSTALL file in the
top level of the distribution for details on the list. <P>

Look for the string <CODE>FIXME</CODE> in source files to tag minor bugs
and potential problems that could use fixing. <P>

Don't try to auto-detect OS features in the main body of the C code.
That's the job of the configuration system. <P>

To hold down complexity, do make your code data-driven.  Especially,
if you can drive logic from a table filtered out of
<CODE>include/Caps</CODE>, do it.  If you find you need to augment the
data in that file in order to generate the proper table, that's still
preferable to ad-hoc code -- that's why the fifth field (flags) is
there. <P>

Have fun!

<H1><A NAME="port">Porting Hints</A></H1>

The following notes are intended to be a first step towards DOS and Macintosh
ports of the ncurses libraries. <P>

The following library modules are `pure curses'; they operate only on
the curses internal structures, do all output through other curses
calls (not including <CODE>tputs()</CODE> and <CODE>putp()</CODE>) and do not
call any other UNIX routines such as signal(2) or the stdio library.
Thus, they should not need to be modified for single-terminal
ports. 

<blockquote>
<code>
lib_addch.c
lib_addstr.c
lib_bkgd.c
lib_box.c
lib_clear.c
lib_clrbot.c
lib_clreol.c
lib_delch.c
lib_delwin.c
lib_erase.c
lib_inchstr.c
lib_insch.c
lib_insdel.c
lib_insstr.c
lib_keyname.c
lib_move.c
lib_mvwin.c
lib_newwin.c
lib_overlay.c
lib_pad.c
lib_printw.c
lib_refresh.c
lib_scanw.c
lib_scroll.c
lib_scrreg.c
lib_set_term.c
lib_touch.c
lib_tparm.c
lib_tputs.c
lib_unctrl.c
lib_window.c
panel.c
</code>
</blockquote>
<P>

This module is pure curses, but calls outstr():

<blockquote>
<code>
lib_getstr.c
</code>
</blockquote>
<P>

These modules are pure curses, except that they use <CODE>tputs()</CODE>
and <CODE>putp()</CODE>:

<blockquote>
<code>
lib_beep.c
lib_color.c
lib_endwin.c
lib_options.c
lib_slk.c
lib_vidattr.c
</code>
</blockquote>
<P>

This modules assist in POSIX emulation on non-POSIX systems:
<DL>
<DT> sigaction.c
<DD> signal calls
</DL>

The following source files will not be needed for a
single-terminal-type port.

<blockquote>
<code>
alloc_entry.c
captoinfo.c
clear.c
comp_captab.c
comp_error.c
comp_hash.c
comp_main.c
comp_parse.c
comp_scan.c
dump_entry.c
infocmp.c
parse_entry.c
read_entry.c
tput.c
write_entry.c
</code>
</blockquote>
<P>

The following modules will use open()/read()/write()/close()/lseek() on files,
but no other OS calls.

<DL>
<DT>lib_screen.c
<DD>used to read/write screen dumps
<DT>lib_trace.c
<DD>used to write trace data to the logfile
</DL>

Modules that would have to be modified for a port start here: <P>

The following modules are `pure curses' but contain assumptions inappropriate
for a memory-mapped port.

<dl>
<dt>lib_longname.c<dd>assumes there may be multiple terminals
<dt>lib_acs.c<dd>assumes acs_map as a double indirection
<dt>lib_mvcur.c<dd>assumes cursor moves have variable cost
<dt>lib_termcap.c<dd>assumes there may be multiple terminals
<dt>lib_ti.c<dd>assumes there may be multiple terminals
</dl>

The following modules use UNIX-specific calls:

<dl>
<dt>lib_doupdate.c<dd>input checking
<dt>lib_getch.c<dd>read()
<dt>lib_initscr.c<dd>getenv()
<dt>lib_newterm.c
<dt>lib_baudrate.c
<dt>lib_kernel.c<dd>various tty-manipulation and system calls
<dt>lib_raw.c<dd>various tty-manipulation calls
<dt>lib_setup.c<dd>various tty-manipulation calls
<dt>lib_restart.c<dd>various tty-manipulation calls
<dt>lib_tstp.c<dd>signal-manipulation calls
<dt>lib_twait.c<dd>gettimeofday(), select().
</dl>

<HR>
<ADDRESS>Eric S. Raymond &lt;[e-mail]&gt;</ADDRESS>
(Note: This is <EM>not</EM> the <A HREF="#bugtrack">bug address</A>!)
</BODY>
</HTML>