![[ TABLE OF CONTENTS ]](../gx/indexnew.gif)
![[ FRONT PAGE ]](../gx/homenew.gif)
John E. Davis of the Center for Space Research at MIT has written an interpreted programming language called Slang, which has a C-like syntax. He has written several programs using this language, including the slrn newsreader and the emacs-like Jed editor. Lately a few other programmers have begun to make use of Slang; one reason for this is that Slang allows the use of color in a text-mode program which will display equally well in an rxvt window under X.
Applications which are linked with the Slang library always seem to be text-mode programs. Typically Linux text-mode applications use the ncurses library to handle screen display. Ncurses enables the use of menus, a certain amount of color, and a more complex screen layout. These traits don't always translate well into an X-Windows environment; i.e. running in an xterm or rxvt window. If an application is linked with the Slang library instead its behavior is more consistent between the console and X sessions, especially when started from an rxvt window.
I get the impression that the xterm terminal emulator is used more commonly than rxvt, though this may be due more to tradition than innate superiority. Rxvt has been revised several times recently and in its current form (version 2.19) has much to recommend it. One feature which I appreciate is that it's memory usage is much lower than that of xterm. Rxvt handles color requests well, both background/foreground specifications and extension-specific colorization such as "color-ls". The most recent version even allows the use of Xpm images as background, similar to a web-page, though as with a web-page a background image would have to be carefully chosen so as not to obscure the text.
Some xterm variants make use of color, but some don't. I find the plenitude of xterms and color-xterms rather confusing; it's hard to tell just which ones you have, and they vary from distribution to distribution. Then there is xterm's Tektronix compatibility, which I've never seen a use for. Reading the xterm man page I get the impression that xterm was developed for older mainframe-and-terminal systems.
I'm sure as the benefits of Slang become more widely known we shall see more text-mode applications with Slang support included. There very well be others than the above-listed out there; these are just the ones I've run across.
Precompiled binaries for slrn, lynx, and the Jed editor (with Slang statically linked, I assume) are available at ftp://sunsite.unc.edu and its mirrors . I used these for some time, but recently I obtained the source for Slang and compiled a shared library. The advantage of this approach is that you can compile binaries which dynamically link the Slang library at runtime. Your executables will be smaller, and one shared library can service any number of Slang-using applications. Another advantage to obtaining the source distributions is that you'll end up with more documentation.
John E. Davis's creations (slrn, Jed, and the Slang sources) are available at their MIT home site. The most recent versions, as well as beta versions, can be found there.
This Mexican site is the source for the most recent versions of the Midnight Commander, as well as rxvt.
Beta versions (which seem stable to me) of Michael Elkins' Mutt mail program are available from this FTP site. Maybe you can get it to compile with Slang!
Lynx binaries with Slang support can be found at sunsite and its mirrors.
The source for the latest and greatest of the Dosemu releases can be found at the tsx-11 FTP site. (Version 0.64.1 was released in November).
If you're like me and work at the console often, you'll find it's nice to have applications available which work well (and look good!) in an X session too. I think you will be pleased with the high quality and low memory usage of the above-listed apps.
I've been writing these short reviews and other articles for the Gazette since issue number seven. Even with the short lead time inherent in a WWW-based publication it seems like new releases and URL changes often happen right after I submit an article. The status of several of the programs has changed since I wrote of them, so I thought I'd take this opportunity to list some of these changes.
By the way, I appreciate all of the email I've received in response to my articles; feel free to write if you have any comments or criticism.
It is a common practice to use the rescue/boot disks supplied with a Linux distribution if filesystem problems occur and you need to boot from a floppy. Typically these disks consist of a bootable compressed kernel on disk 1, with the second disk containing basic maintenance tools such as fsck.
On the few occasions I've had to boot from such disks the transition from my familiar Linux environment to the bare-essentials, limited boot-disk system (constrained by the size of a floppy disk) has been disconcerting, to say the least. Typically if an editor is available it's a small one with which I've never worked, and many of the tools I'm used to having around aren't there.
Recently Tom Fawcett has been refining a suite of customizable Perl scripts which make the creation of boot-disks from scratch easier. YARD (for Yet Another Rescue Disk) makes use of (and requires) the optional Linux kernel compressed ramdisk option, which allows you to load a compressed disk image into memory at boot-up. Paul Gortmaker has written a lucid explanation of the new ramdisk options in the file "ramdisk.txt", which is in the Documentation subdirectory of recent kernel source releases.
The Yard distribution contains two files which need to be edited as a first step. Config.pl is a Perl script which sets such preferences as the type of floppy you're using and whether you are making a single boot-disk or a double. The Bootdisk_Contents file contains a list of all of the files and utilities you would like on your disk(s). This file needs to be edited heavily, as it includes much more than will fit on even two disks. Anything you like can be included in this file.
The next step is to run the Perl script make_root_fs. This script gathers up all of the files you've specified (as well as all libraries upon which they depend) and constructs a root filesystem upon whichever device was specified in the Config.pl script. A ramdisk works well. The new filesystem is then compressed with gzip into a single file in your /tmp directory. Once this process is complete yet another Perl script, check_root_fs is run, which makes sure that all needed libraries,etc. are present.
After all of this preparation you're ready to actually write the rescue disks; here's where you find out if you've attempted to cram too much into them. The write_rescue_disk script first copies your compressed kernel (vmlinuz) onto the disk (the first disk if it's a two-disk set) and then copies the compressed filesystem image you've constructed onto whatever is left. It took me several tries to pare down what I wanted Initially on the disks to what would actually fit. The virtue of the Yard system is that all you need to do to try again is re-edit the Bootdisk_Contents file and re-make the filesystem. Yard also writes log-files which can be helpful in diagnosing problems.
Modular kernels are great, but if you boot a kernel image and a capability you need is a demand-loaded module you're out of luck. Yard sidesteps this potential problem by including your modules directory in the compressed filesystem, as well as making sure that the kernel-daemon /sbin/kerneld is started at boot-up.
The result of this process is a customized miniature Linux system. It's a nice feeling to know that if your filesystem is in shambles due to a power outage or a beta program run amuck that you at least have familiar tools available.
Once you've managed to edit a set of Yard configuration files which will successfully write working rescue disks, consider saving copies of these files in case the disks become corrupted. I just replaced the supplied files with my edited copies, then tarred and gzipped the Yard distribution and saved it to floppy.
Yard gives you the option of using or not using Lilo to boot your disks. I first tried Yard with Lilo, as Lilo has always worked well for me. It wouldn't work with my Yard disks, so I disabled that option. I'm using an old version of Lilo, left over from my original Slackware 3.00 Linux installation, which may explain this failure. Yard works fine without it. Lilo might be necessary if you need to include parameters in order to boot your system, such as those required for some SCSI hard disks.
Yard is available from the Yard home-page, as well as from the sunsite archive and its mirrors. It's well worth trying if you want the ultimate in control over just what is included on your rescue disks.