various  awk/sed/sh  scripts  from  a master table include/Caps; 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).   Thus, adding a new capability is usually pretty trivial, just a matter   of  adding  one  line to the include/Caps file. We'll have more to say   about this in the section on Source-Form Translation.Use Capability Resolution   The  background  problem  that  makes  tic tricky isn't the capability   translation  itself,  it's  the  resolution of use capabilities. Older   versions would not handle forward use 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.   This  won't  do  for  ncurses.  The  problem  is  that  that the whole   compilation  process  has  to  be embeddable in the ncurses 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.   So  our  tic  is  designed  to  parse  an  entire terminfo file into a   doubly-linked  circular  list of entry structures in-core, and then do   use  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.   And   this  is  exactly  how  the  embedded  version  works.  But  the   stand-alone  user-accessible  version  of  tic  partly  reverts to the   historical strategy; it writes to disk (not keeping in core) any entry   with no use references.   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 three hours, rather than the twenty seconds or   less typical on the author's development box.   So. The executable tic passes the entry-parser a hook that immediately   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.   Name  collisions  will  still  be  detected,  just not as cleanly. The   write_entry()   code   complains  before  overwriting  an  entry  that   postdates  the time of tic's first call to write_entry(), Thus it will   complain  about overwriting entries newly made during the tic run, but   not about overwriting ones that predate it.Source-Form Translation   Another use of tic 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 captoinfo(1) manual   page.   The  translation output code (dump_entry() in ncurses/dump_entry.c) is   shared  with  the  infocmp(1)  utility.  It  takes  the  same internal   representation  used  to  generate  the  binary  form  and dumps it to   standard output in a specified format.   The  include/Caps  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.   For  circumstances where you need to do algorithmic translation, there   are  functions  in  parse_entry.c called after the parse of each entry   that are specifically intended to encapsulate such translations. This,   for  example,  is  where  the AIX box1 capability get translated to an   acsc string.                                Other Utilities   The  infocmp  utility  is just a wrapper around the same entry-dumping   code  used  by tic for source translation. Perhaps the one interesting   aspect  of  the  code  is the use of a predicate function passed in to   dump_entry()  to  control  which  capabilities  are  dumped.  This  is   necessary in order to handle both the ordinary De-compilation case and   entry difference reporting.   The  tput  and  clear  utilities  just  do an entry load followed by a   tputs() of a selected capability.                           Style Tips for Developers   See   the  TO-DO  file  in  the  top-level  directory  of  the  source   distribution for additions that would be particularly useful.   The  prefix  _nc_  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.   Look  for  the  string  FIXME  in  source  files to tag minor bugs and   potential problems that could use fixing.   Don't  try  to auto-detect OS features in the main body of the C code.   That's the job of the configuration system.   To hold down complexity, do make your code data-driven. Especially, if   you  can drive logic from a table filtered out of include/Caps, 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.   Have fun!                                 Porting Hints   The  following  notes  are intended to be a first step towards DOS and   Macintosh ports of the ncurses libraries.   The  following library modules are `pure curses'; they operate only on   the  curses  internal  structures,  do all output through other curses   calls  (not  including  tputs()  and putp()) 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.     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   This module is pure curses, but calls outstr():     lib_getstr.c   These  modules  are  pure  curses,  except  that  they use tputs() and   putp():     lib_beep.c   lib_color.c   lib_endwin.c   lib_options.c   lib_slk.c     lib_vidattr.c   This modules assist in POSIX emulation on non-POSIX systems:   sigaction.c          signal calls   The    following   source   files   will   not   be   needed   for   a   single-terminal-type port.     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   The  following  modules will use open()/read()/write()/close()/lseek()   on files, but no other OS calls.   lib_screen.c          used to read/write screen dumps   lib_trace.c          used to write trace data to the logfile   Modules that would have to be modified for a port start here:   The  following  modules  are  `pure  curses'  but  contain assumptions   inappropriate for a memory-mapped port.   lib_longname.c          assumes there may be multiple terminals   lib_acs.c          assumes acs_map as a double indirection   lib_mvcur.c          assumes cursor moves have variable cost   lib_termcap.c          assumes there may be multiple terminals   lib_ti.c          assumes there may be multiple terminals   The following modules use UNIX-specific calls:   lib_doupdate.c          input checking   lib_getch.c          read()   lib_initscr.c          getenv()   lib_newterm.c   lib_baudrate.c   lib_kernel.c          various tty-manipulation and system calls   lib_raw.c          various tty-manipulation calls   lib_setup.c          various tty-manipulation calls   lib_restart.c          various tty-manipulation calls   lib_tstp.c          signal-manipulation calls   lib_twait.c          gettimeofday(), select().     _________________________________________________________________    Eric S. Raymond <esr@snark.thyrsus.com>   (Note: This is not the bug address!)