ncurses: Portable Screen-Handling for Linux
Since you are clueful enough to subscribe to Linux Journal, you may already know that Linux includes a clone of the Unix screen-handling library, curses(3). You may also know that Linux's ncurses(3), like its ancestor, is a general screen-handling library that supports all popular asynchronous terminal types, including the color-ANSI and vt100-like capabilities of most Linux consoles. You've certainly run a program that used curses, vi, perhaps, or any of a dozen screen-oriented games.
You may not know that there are actually two major flavors of curses, with differences that are important for portability. You probably don't know (unless you have read ahead) that post-1.9 releases of ncurses include dramatic new features that will make them far more reliable, powerful, and useful than their predecessors.
The first curses library was hacked together at the University of California at Berkeley in about 1980 to support a screen-oriented dungeon game called rogue. It leveraged an earlier facility called termcap, the terminal capability library, which was used in the vi editor and elsewhere.
Termcap consisted of a simple text database format for describing the control sequences and capabilities of serial terminals. Before the ANSI standard hundreds of mutually-incompatible terminal types competed in the market; termcap described them in a standard way that made it possible for vi's screen-painting code to be terminal-independent.
The curses library took this one step further, by defining a relatively clean C API (applications programming interface) to hide the details of termcap-based screen painting. This facility was a terrific success, and gets almost all the credit for lifting Unix out of the line-oriented interface style inherited from its early days on ASR-33 Teletypes.
The success of curses did not go unnoticed at Bell Labs. Later System III releases and System V Release 1 included an enhanced curses library with many new features. These included:
Support for multiple screen highlights (BSD curses could only handle one “standout” highlight, usually reverse-video).
Support for line- and box-drawing using forms characters.
Recognition of function keys on input.
Color support (in later versions).
Full support for sub-windows.
Support for pads (windows of larger than screen size on which the screen or a sub-window defines a viewport).
The Bell Labs curses was upward-compatible from BSD curses, and much more powerful. However, its designers made one controversial major change; they scrapped the all-text termcap format for terminal capability descriptions, opting instead for a binary format called terminfo.
The most important reason for changing formats was that the BSD termcap database was getting so large that sequential searching took significant overhead. The terminfo format (binary capability blocks living in a bushy directory tree), by contrast, was optimized for fast lookup and fast loading.
In doing changing to a binary format, however, Bell Labs curses gave up two valuable features: extensibility and the ability to edit terminal descriptions with standard text tools. The termcap routines had never actually cared what the capabilities meant to the program using them, whether it was curses or something else. Thus, it was easy to add new capabilities and new interpretations; in fact, later BSD releases used the same code for printer- and modem-capability databases. In terminfo, by contrast, additions to the database format required a recompile of the library.
AT&T's no-source-code policy meant that Bell Labs curses itself never got a chance to outcompete the BSD version in the hacker community. Worse, the tradeoffs in the terminfo format meant that the largely BSD-centric hacker culture had a passable excuse to denigrate the major new capabilities in Bell Labs curses.
For more than five years, then, freeware authors writing screen-oriented programs were in the vexing situation of having to design around the older, less-capable BSD interface even on machines that supported the Bell Labs curses.
Around 1982, noted hacker Pavel Curtis (formerly of Xerox PARC, now perhaps best known for his MOO project) attacked this problem head-on by starting work on a freeware clone of Bell Labs curses. This package was part of Pavel's personal toolkit; it was not widely distributed, or even very well known, until Zeyd Ben-Halim, email@example.com, took over the development effort in late 1991. I got involved in late 1993 to support a screen-oriented multi-user Unix BBS I was developing.
The early ncurses versions had some serious drawbacks. The biggest problem was that a good many important Bell Labs curses capabilities were absent, leaving annoying and unpredictable gaps in the API. The documentation was poor and not suited to on-line browsing. Very little systematic compatibility testing against Bell Labs curses had been done. Last, but not least, all versions up to 1.8.5 had serious bugs.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Returning Values from Bash Functions
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Rogue Wave Software's Zend Server
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide