The Text Pistols
A growing number of renegade geeks are choosing to shun the full-blown GUI in favour of apps such as GNU screen, GNU Emacs and in rare instances a tiny window manager. Martin Howse checks into the world of the stripped down interface
________
It's hard to argue that Unix is anything other than a textual environment. Commands are text-based and manipulate information primarily as text. Human and machine readability overlap with a clarity unknown to users of other OSes. So how well do GUI so-called desktops or desktop environments play with this fundamental Unix approach? One could well envisage some kind of GUI which could follow the Unix model of pipes and information flow, and there may well be such a project buried deep beneath the sludge of abandoned projects on SourceForge, but the end result would still rely heavily on textual selection. Unix-based OSes, particularly with an overwrought and in some ways elegant GUI such as Mac OS X do have a tough time integrating the two approaches, and the command line is very much treated as a tolerated, yet rather distant older relative. The default terminal app seems clunky and washed out in comparison with the brighter, broader desktop. Thankfully GNU/Linux users do have a choice and a good many geeks would rather exercise their command line chops at a healthy distance from the rodent infested world of the desktop GUI. Some have even gone so far as to pay homage to the green screened days of their forebears, picking up an elegantly designed DEC terminal (see DECed Out) and coding strictly from this revered beast over a serial line. Indeed, working in what some may see as a highly restricted manner, say straight from the console, can readily and quickly hone Unix skills and familiarise users with the richness of the shell.
Nevertheless, which ever way you pan it, and command line advocates can do a good job at selling even the most spartan app, life at the console can get pretty claustrophobic with little wallpaper to brighten matters and a rather tiresome ctrl, alt and function key finger three step to further induce melancholia. Even comic fonts a la early Slackware, which could well be selected during one of the most exciting install moments, soon become tiresome. The advent of full framebuffer support for a range of graphics cards does change matters and can readily be determined as a deciding factor in a stand off between console and ultra minimal desktop as environment of choice. With such a decision at the top of the tree in a hierarchy of components selected to please the contemporary text pistol, we can begin to assemble a full roster of tools and tips. Choosing the role of X pistol or text pistol is a tough call. At the next stage down the hierarchy, this choice will impact on our toolset. Terminal emulators such as xterm and rxvt make little sense on a real terminal. And framebuffer tweaks and minute console display apps are hardly at home on top of mighty X. Further down the line apps are reasonably generic, little caring if they live on the console, within a window manager such as Ion2, or even on the wire serial-wise dialled through to some remote user. Multiplexors such as GNU Screen and managers of monitor real estate such as SplitVT are less obvious examples here. Editors such as Vi are clearer candidates, but GNU Emacs does exhibit different behaviour under X. Lynx, Links, w3 and other such text-based, ubiquitous browsers are essential items within the renegade text pistols bag of tools. Beneath these can be found generic text and data manipulation tools such as sed and awk and more domain specific and development biased tools. Shell scripts and the shell itself could also be blocked in at this level, and though under popular distros with KDE or GNOME defaults it may be easy to forget such facts, text rules throughout our hierarchy. Code is text, commands are text and information primarily is and should be textual in a human readable and thus open networked environment.
Consoling thoughts
Whilst ultra minimal window managers, such as the appropriately titled ratpoison, do offer the best of both worlds for text pistols who may want to fire up the odd GIMP session once in a while, running barefoot with the plain old console does appeal to purists preferring a totally distraction free environment. Yet, unless you prefer a decidedly old school feel, handwritten style font included, chances are you'll wish to console around in frame-buffer mode which allows for smaller text sizes at higher resolutions. Support for this essential mode, offering direct access to the graphics card memory, is enabled on most modern distros booting binary kernels, or can be compiled into the kernel if you're dealing strictly with the source. Plentiful howtos exist for such a common operation, yet it's worth remembering that both colour depth and resolution data must be passed to the relevant bootloader by way of a decimal frame-buffer code. A common option would be to specify vga=791 which allows the console to kick in at 1024x768 with a 16 bit depth. Some graphics apps, such as basic image viewer fbview, or masterful multimedia tool MPlayer, can make full use of frame-buffer support, and Links, a pleasant web browser, which lives further down our tree of components, can render images direct to the frame-buffer. A range of libraries exist for programmers to make full use of the frame-buffer without rehashing low-level code. Well documented APIs for libraries such as DirectFB or oFBis, from the respected NoCrew team, should ensure a steady stream of apps. And, given that the very popular and incredibly easy to use SDL (Simple DirectMedia Layer) library, libSDL, can throw data at our lowly framebuffer, many apps which abstract graphics by way of this API should run well without a single thought of X11.
Although true text pistols may frown on such distractions, a graphical login is possible at the framebuffer thanks to our flexible friend Qingy, which stands for Qingy is not getty. Various gettys unrelated to that famous family pop up with reference to the serial console (see DECed Out), but for now we can think of getty as sole handler of the login prompt. Qingy replaces getty with a pleasant graphical login screen which can thence fire up a customised console which can even be altered across each tty or terminal.
If frame-buffer support is unavailable, perhaps due to hardware or compilation issues, there's still little to stop our graphics hungry text pistol getting a quick image fix. It may well be old and crusty, and pack in a raft of demos which would well suit any retro 'puter party, but SVGAlib is fast and fun to use. Plenty of old school apps make use of this easy to learn graphics display library which chucks data at a VGA card with wild abandon and a healthy disregard for local security. If you're a fan of the instant hang or glitchy display crash then a mis-configured SVGAlib really is a surefire hit. Nevertheless, configuration under /etc is not so tricky and a good number of cards are supported. With the right options supplied to ./configure at compile time, apps such as MPlayer will play well with SVGAlib. And compiling support into libSDL again means that graphical apps exploiting this library should do fine on the console. GGI is another option, aiming to unify access to graphics hardware. It started life as an alternative to SVGAlib, but now floats above such backends or targets, including the frame-buffer, and abstracts details of implementation. On the SVGAlib side it's worth mentioning zgv, originally a neat SVGAlib only image viewer, but now supporting SDL, which well rounds out an array of graphical console apps. Of course, old school and hardcore crews will already spurn such approaches, in favour of aalib, which can equally wrap up SVGAlib innocuously or itself be wrapped as backend by ubiquitous libSDL. AVIs will never look the same, courtesy of the crack team of aalib and MPlayer. Classic films of certain genres rendered as high res colour ascii art are well worth a second viewing. And just to put a new spin on the old X11 versus console debate, why not confuse matters altogether by running an ascii aalib-based X server on top of GGI, XGGI running on an SVGATextmode tweaked good old console. KDE has never looked so good.
Lesser evil
Such a preponderance of graphics-based apps on the console may well have our text junkies running for cover, and quite possibly into the hands of a merciful window manager such as the well titled evilwm, part of a large family of stripped down environments running nevertheless on the dreaded X. Though GNU Screen and SplitVT, grappled with in DECed Out, decently multiplex screen space, the overhead of X is not so great these days and such window managers do afford a measure of transparency and elegance. Simple tiling of windows is one bonus, minimal contextual information another, and under some environments floating windows can be used to good effect. Evilwm is a hot favourite in the latter instance with an absolute lack of window decorations perhaps pushing it ahead of fellow traveller Ion2 in the text pistols stakes. Indeed, Py-EvilWM, a port of this beast to highly extensible Python, could well be seen as going head to head with Ion2's flexible use of Lua. In either instance, customisation, as with most smaller apps, is a breeze and customary key clobberings can be fixed with a few seconds effort. Ion2, which shares a certain text or type based and distinctly mouse unfriendly approach with evilwm and ratpoison, is a hot favourite, purely in terms of flexibility. By default, Ion2 within both tiled and floating window modes does offer some window decoration by way of a contextual indicator such as xterm<1> and the like. Such behaviour can readily be altered, or indeed apps and xterms can be full screened with a simple alt and return two step. Ion2 is also highly configurable when it comes down to a vast army of keystrokes or shortcuts manipulating behaviour. And a grammar of tiles and frames which can attain some level of persistence with apps does make for flexible screen configurations. Wmii (Window Manager Improved 2) represents a recent addition to the family of minimal window managers with a feature set very much approximating Ion's and much touted as allowing for Vim, or Vi improved, interaction. Tabbed, tiled and conventional floating windows are all available, and, in common with a raft of other such hardcore projects, a rather novel architecture is implemented. In this instance, inter-process communication between heavily modularised window manager components is tackled by way of the authors own libixp, a virtual file system based intriguingly on the 9P protocol from Plan 9 OS.
Of course some would argue that wmii, with features such as fading through virtual desktops, and Ion, particularly with the Ion2 iteration, go too far, and the developer of evilwm in rather double edged terms does describe Ion as a less bigoted project. Ratpoison, and Lisp-based brother Stumpwm boil the window manager recipe strictly down to key bindings and tiling. Of course a logical next step would be to run bare and naked without window manager support, by way of an .xinitrc script or plain old xinit command.
Yet even with such a stripped down, almost non-environment choices do abound and this ever present attribute of free software is both a blessing and a curse. A vast array of terminals, or, more correctly, terminal emulators are on offer under X, many boasting an often confusing mix of legacy features and bloated novelties. You can select an xterm, an eterm, an aterm, or even rxvt, a plain old terminal, which is far from simple, and under KDE and GNOME feature packed offerings are also up for grabs. Terminal characteristics can be specified from the command line, menu bars and in some cases floating arrays of icons. The range of contemporary terminal emulators on offer mirrors the sheer diversity of hardware terminals abounding in the 70s which Unix and application developers had to attack. It was Bill Joy, creator of the Vi editor, who provided a long running solution, abstracting away the differing features and control codes of such creatures, with a generic interface plugged into a database of terminal drivers known as termcap. It's a single text file which is found under /etc on all GNU Linux systems today and this vast catalogue does make for fascinating bedtime reading.
Far from being purely anecdotal, such historical considerations do impact on our humble eterms and xterms. Unknown to many users the more or less ubiquitous xterm truly emulates a green screened forebear such as the DEC VT220, VT102 or Tektronix 4014 models. Thus to any text-based app such as Vi, the lowly xterm will appear and behave as if you had one of these pleasant to use relics right at hand. Xterms rich history is readily apparent both across the vast man pages for this seemingly tiny tool, and if you attempt to configure an xterm by holding down ctrl and pressing one of the mouse buttons. A vast array of command line options control all aspects of an xterm's look, feel and behaviour. The more or less identical .Xresources and .Xdefaults files can further override such settings, and the first file is used when the window manager is fired up. Ironically the xterm's development dates back pre-Linux and even pre X. The Xterm has spawned all manner of progeny from both its code-base and its feature set, and the authors of xterm do stress its emulation capabilities above all else. Other terminals are not so exacting and few apps demand such a high level of attention to detail. If you have little need for Tektronix emulation, you can always use an eterm, or one of its predecessors such as rxvt or xvt. Other terminals of note include Blurt (Bloody Lame Useless Redundant Terminal), if only for its name, and Mrxvt, which packs in both the pseudo-transparency of aterms, and the tabbed terminal capabilities of GNOME and KDE-based terms without the need for library bloat or annoying widget sets. Indeed, such a contemporary terminal as Mrxvt, formerly known as Materm, does put the humble xterm to shame, particularly when it comes down to ease of configuration. Yet, one patch worth applying if you do have the xterm source does offer a moderate update. The xterm-hyperlink-patch allows for double-clicked text to be sent to any command. In this instance the authors of the patch direct the text to a shell script which can sift out requests to all manner of networked service.
Enough of X
Once past the vexing X question it's high time to tackle more carefree apps which little care where they do their thing. And ed presents one such app which bothers even less about the user and has strictly no idea about who or what is running it and in which environment it is called. Ed well introduces the text pistols roll call of text editors and if anything can be relied on when administering a remote and unknown system, it's that tiny ed is on board. Ed is also unusual in being one of only two commands which feature as spoof man pages within the GNU collection of hacker humour. As well as giving an idea of ed's extreme user friendliness, this witty fake man page exquisitely takes off all manner of editor evangelism, with both Vi and Emacs camps well parodied. Yet, alongside the mooted ubiquity, ed does have some things going for it, though describing ed as "the true path to nirvana" is far from the truth. Those who mock the bloat of Emacs would also do well to compare ed to their own chosen editor. Being a line-based, totally non-WYSIWYG editor which works with a buffer one line at a time using simple keystroke commands, ed is easy to automate and does support complex text substitution commands. It's minimal to the point of autism, with separate commands for showing, moving around in and replacing text, and outputting a rather blank ? to signal nearly every error. The mock man page lovingly reproduces a question mark and expletive ridden sample user session and any newbie will be able to attest to the veracity of this example. Ed's use of modes, which must be remembered and which change the functionality of commands is one such cause for cursing. Yet, ed is still firmly ensconced within the text pistols historic hall of fame. Indeed, our good friend grep is named after the command sequence used to similar effect under ed.
Emacs users can well use ed as a stick to beat Vi or Vim (Vi improved) proponents, who in olden days would refer to that mega-meta-editor with a whole list of acronym standins. These included "Eight Megs And Constantly Swapping," and "Eventually Munches All Computer Storage," referring to the sheer binary and source size and memory footprint of that beast, and which really would have meant a good deal back in the day. In a fun way there was little love lost between the two warring camps, and it's a commonplace these days to replace such flamefests with often ill thought out diplomacy. Vi, which is aliased to Vim on most GNU/Linux systems, is commonly considered as being truer to the Unix way of doing things in being good at one thing and one thing only. In this instance, that task is editing text with an emphasis on coding. On the other hand GNU Emacs does more things than you'd care to name and is wonderfully extensible and configurable. It's a monstrous environment which can be quite overwhelming for new users. Yet integration is the name of the game here and there's little thus in contradiction with the way of Unix. The argument should rather be that Emacs takes away some if not all of a Unix-like OS's functionality by offering pluggability with greater control. Indeed, a common hacker email signature file reads "Emacs is my OS and Linux its device driver." There's a lot of truth behind this brazen cliche. The shell is perhaps too brittle, fine grained and with little in the way of state. Emacs is the non plus ultra of the true text-pistols hacking tools. Ignoring graphical versions such as default GNU Emacs under X, or the XEmacs fork, Emacs is keyboard and text based in the extreme. Extendibility and customisation is by way of suitably self documenting Emacs Lisp. Text formatting operates primarily under the expressive TeX text processing language. And all manner of text, more text and yet more text is available and processable through built in browsing and mail capabilities, advanced information mangling facilities, directory editing functionalities, calendering and diary upkeep tools and much, much more. You'll even be able to check in with Eliza, the classic computerised shrink and ascii art receives good attention. Advanced hypertext, rolodexing and indexing functionalities extend GNU Emacs and such packages, which may now appear old-fashioned in the light of impending web technologies, still provide room for both productive use and satisfying experimentation. Hyperbole and the Remembrance Agent (Remem) are two such intriguing apps. Remem is particularly unique in actively sifting through a user's data, and suggesting within an Emacs buffer coincidental or perhaps relevant material. Both are old school apps which well demonstrate the power of open text. In a future installment we'll check out lower level apps for the text pistol's toolkit, with particular attention to Unix power tools, and contemporary technologies which boost the green screen with a hotwire connection to the semantic web.
DECed out
God save GNU Screen. And the Emacs regime. Green screened terminals may well be the stuff of myth and history within hacker culture, and many a description of marathon hacking sessions commences with a reference to their unhealthy glow, but the decent build quality of keyboard and somewhat tranquil aura do make of such oft junked beasts a useful interface for coders. DECs VT series, particularly the well featured VT550, is a particular favourite sporting Digital's legendary minimal cream styling. And in addition to the lure of this aesthetic, and a pleasantly quiet and pared down environment which makes for good concentration, serial terminals do offer other benefits. With little configuration of a kernel build, and even some tweaking of modern server BIOS, key messages which can readily assist in debugging can be gleaned from the green screen. And plugging a long serial cable into racked up servers is certainly easier than hanging a monitor off each machine, whilst still providing sufficiently low level access.
Yet as well as often proving troublesome to set up, with much getty grappling and many minicom sessions involved, the sole console approach of the serial terminal does prove more than restrictive, and simply cries out for multiplexing, or at least some tiling. GNU Emacs, packing in frames, buffers and splitting of windows, does offer some escape from our claustrophobic single screen, but in wider instances GNU Screen and SplitVT are always on hand. GNU Screen is a hot favourite, even in combination with GNU Emacs for serious power users. GNU Screen well earns the title of window manager, and advanced functionality can readily be used to manage multiple processes, attaching and re-attaching these to specific windows. Sessions at the terminal can well be detached, tucked away and preserved for any number of days, allowing for a good degree of persistence. Screen can split screens, multiplex multiple screens, or sessions, onto the one terminal and it even allows for logging and advanced copying and pasting functionalities. You can even monitor plexed out and thus hidden windows for activity. Heck, GNU Screen even lives a double life as a terminal emulator of the good old VT100 variety, and this does further complicate matters as it must itself run under a terminal. Screen is by now means easy to learn, with somewhat terse documentation. With an exit route at hand, simply fire up Screen, hit control and the a key, Screen's generic command combination, and then ? to see what's on offer. Online tutorials can readily be found for this incredibly versatile tool. And finally, if a junked serial terminal proves hard to find, you can run with plain old Minicom, as emulator, on a Linux box, or check out the LTSP (Linux Terminal Server Project) for larger deployments which may well recall the good old days of multiple VTs hanging off one clunky VAX.
key links
ASCII Rock: http://projects.c505.com/projects/ascii_rock/mov/SP-godsavethequeen.mov
GNU Screen: http://www.gnu.org/software/screen
SplitVT: http://www.devolution.com/~slouken/projects/splitvt
DirectFB: http://www.directfb.org
Qingy: http://qingy.sourceforge.net
SVGAlib: http://www.svgalib.org
aalib: http://aa-project.sourceforge.net/index.html
aalib-based X server: http://www.meow.org.uk/stan/xserver
Ion2: http://modeemi.cs.tut.fi/~tuomov/ion
evilwm: http://evilwm.sourceforge.net
ratpoison: http://ratpoison.sourceforge.net
wmii: http://wmi.modprobe.de
Mrxvt: http://materm.sourceforge.net
ed: http://www.gnu.org/fun/jokes/ed.msg.html
Vim: http://www.vim.org
GNU Emacs: http://www.gnu.org/software/emacs/emacs.html
Remembrance Agent: http://www.remem.org
Hyperbole: http://www.gnu.org/software/hyperbole/hyperbole.html
LTSP: http://www.ltsp.org
Text-Terminal-HOWTO: http://howtos.linux.com/howtos/Text-Terminal-HOWTO.shtml