Linux Gazette November, 1995

A Publication of the Linux HomeBoy WebPage Series

"The Linux Gazette...making Linux just a little more fun...!"

Copyright (c) 1995 John M. Fisk

For information regarding copying and distribution of this material see the COPYING document.
Linux Home Boy Pages logo created using David Koblas' excellent program XPAINT 2.1.1

Table of Contents

Topics in this issue include:

News Flash!

This One's for You!

Well, I've had so much mail recently, and so many great suggestions and such that this month's LG is "dedicated" to those of you that have written. This thank you list is pretty long and includes:

Again, I'd like to extend an open invitation to anyone that wants to write and offer a suggestion, tip, trick, or idea. Thing is... any time you do one of those "slap-your-forehead-cause-this-is-just-too-cool" maneuvers, then take a moment and drop a note!


If you've come across something that you think is pretty cool, or you've finally gotten something to work, chances are that there are a LOT of others who are in the same boat, but haven't had the good fortune of an epiphany yet...

Share the wealth!

And don't worry about speling [sic!] or formats or how good your English is... (as you can see from my writing, things are kinda lax around here :-) just drop a note and I'll be happy to include it.


Linux Gazette taking a Christmas Break!

Yup, things here have been so hectic lately that I've promised my wife that I'll be taking a Christmas break from the Linux Gazette. I really do need to spend some time with her and my family and so will probably NOT be putting out a December edition.

Therefore, I just want to say that I hope you all had a great Thanksgiving (I put on my requisite 3 pounds after stuffing myself repeatedly :-) and wish you all a very Merry Christmas and Hanukkah Season!

Two new host sites to the Linux Gazette!

I'd like to thank Phil Hughes at the Linux Journal and Alan Cox at for graciously offering to mirror the Linux Gazette. For those of you who have been trying to access the LG from Europe, you might appreciate the fact that now there's a friendly, neighborhood mirror site on your side of "the pond" :-)

You'll find information about the LG at these sites:

The Linux Journal @

If you're getting the LG from these sites, drop these folks a note and let them know it -- and don't forget to say thanks! These folks are providing the LG mirror as a free service to the Linux community. Remember... your Mom always said to remember your "please & thank you's..."

Yes... I'm still working on getting the LG available for ftp... :-(

I sincerely apologize for not getting the LG ready for anonymous ftp this month. I know that it would help a LOT of you out to be able to ftp it rather than trying to get a connection. Also, there are folks who simply don't have WWW access but can do ftp.

Once again, I appreciate your patience. This is one of the December projects and is a high priority.

I'll be putting an announcement in comp.os.linux.announce when things are finally ready to go.

Also, a number of you have expressed an interest in mirroring the LG. After considering how best to handle this I've decided to the following:

  • [1] I'll continue to maintain the Linux Gazette at the "official sites" (Tennessee CommerceNet, RedHat Commercial Linux, The Linux Journal, WWW.Linux.Org). That is, I'll be responsible for fixing all of the messes that I've made and the lousy speling [sic].

  • [2] However, since I've had requests to mirror the LG from Korea, Czechoslovakia, Saudi Arabia, South Africa, Zambia, Venezuela, Sweden, the UK, Denmark, etc..., and because the connections from the US to some of these countries can be SO slow...

    I've decided to make the LG freely available for mirror to anyone that wants to do so. My only request is that, if you decide to do this, you drop me a note and send me two things:

  • What I'm going to do is start a webpage of mirror sites so that any of you that are trying to access these pages from a non-US location can find a site closer to home. I'm also happy to have anyone mirror the LG in the US as well, but I'm particularly interested in making this available to folks who don't happen to live close to Nashville, Tennessee :-)

    Again, this is a high priority and I'll do my best to get things together around mid- to late-December. I'll post an announcement on c.o.l.announce when things are ready to go.

    We're working an a Mailing List! :-)

    Yup! This is VERY unofficial at the moment, but a couple of generous souls have tentatively offered to try and get a mailing list up and running for the Linux Gazette.

    I've gotten a LOT of requests for this and frankly don't have the time myself to do this (nor the technical expertise at the moment). But, there are a couple serious Linux-heads out there that have offered their services.

    If things do work out, then y'all owe these guys a HUGE round of thanks. Again, this is pretty tentative and it may not work out... these guys still have other stuff to do, like go to work each day so that they can get paid each Friday..., and so we'll see.

    If things don't happen to work out, I'll let you know and I'll see if I can work something else out. Keep your fingers crossed...

    Thanks for your patience!

    Precompiled binaries available for XF-Mail!

    After corresponding with several of you about getting XF-Mail to compile I wrote the authors of XF-Mail and asked about precompiled bin's for Linux. Gennady very kindly wrote back and mentioned that these are already available via his ftp server:

    Sender: <>
    From: Gennady Sorokopud <>
    To: John M. Fisk <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: RE: Precompiled binaries for Linux

    Hello John!

    I certanly understand the problem, and i tried to solve it. My site ( contains precompiled binaries for every platform including Linux. If you want to distribute precompiled binary on other FTP sites then go ahead!

    I don't make any limitation of xfmail's distribution and it's completely free.

    On 27-Nov-95 John M. Fisk wrote:

    >Say, I have a favor to ask and an offer to make... :-)
    >After writing up XF-Mail in the Linux Gazette I've had quite a few 
    >letters about it... mostly quite positive.  However, I've had a couple
    >folks write LONG letters about the problems they've had getting it
    >to compile.  I can't begin to imagine what some of them are doing and
    >I know that the current version of libxpm does NOT, at least according
    >to one reader, work -- it compiles cleanly and then seg faults.  When
    >he compiled with the previous version of libxpm it worked fine.

    Yes, i've seen this problem. Latest XPM library has some problems with xforms toolkit.


     Gennady B. Sorokopud - System programmer at NetVision Israel.
     E-Mail: Gennady Sorokopud 
     This message was sent at 11/27/95 13:35:26 by XF-Mail

    So, for those of you that have been having trouble getting XF-Mail to compile, you might try the bin's available at which includes the XPM libraries you'll need as well.

    Good luck!


    -- John

    Welcome to the November edition of the Linux Gazette !

    Well, as I've written many of you over the past couple weeks... I've gotten thoroughly trounced at school recently. My nice, slow semester finally built up a head of steam and I've gotten bull-dozed into the ground. Funny how quickly the memories of miserable "all-nighter's" fades... :-)

    Anyway, I mention that to say that I'm sorry this month's LG is coming out late. I really appreciate your patience and understanding. This has been a HUGE amount of fun and I've enjoyed chatting with a number of you via email.

    Also, I wanted to clear up the copyright thing, since a couple of you wrote about it. Basically, it's pretty simple:

    Pretty simple, eh?

    The basic idea is that the Linux Gazette is a vehicle for the free exchange of ideas! I know I'm sounding like a broken record here, but the point is worth repeating.

    Finally, I am planning to take a Christmas Break with my family. Things have been busy around here and I desperately need to:

    Like I said... it's been kinda busy. Therefore, there probably won't be a Linux Gazette for December. That's the official word. Unofficially, if I get the time and am not taking time from family, I'll probably try to whip up a quickie as I've been playing around with a few neat tricks recently that have been kinda fun. As always, I really appreciate your patience.

    I DO promise to finish the series on FVWM. I'm not going to promise when it'll be finished since I haven't been able to keep these promises very well of late.


    -- John

    Salutations and the MailBag

    Well, as usual, mail in and out of FiskHaus (the 'ol Linux box here...) was fairly brisk. I really appreciate the ideas and suggestions, criticisms and reports of my lousy spelling and HTML errors, and just the chatty notes from one Linux affectionado to another. I've tried hard to drop y'all (that's Nashville for "all of you" :-) at least a short note. For those who asked for help, I also tried to answer things as best I could.

    Keep in mind... I'm NO Linux guru!

    The Linux Gazette is born out of my own experiences, trials and mostly-errors, and the kind suggestions and offerings of others much smarter and more experienced than me. As far as I'm concerned, Linux is the perfect example of "lifetime learning" which is what makes it a HUGE amount of fun.

    Anyway, I'm starting to babble...

    To all who've written... Thanks!

    PPP script follow up by Adam Schlesinger:

    Date: Wed, 08 Nov 1995 09:28:37 CST
    Sender: <adams@Morgan.COM>
    From: Adam Schlesinger <adams@Morgan.COM>
    To: <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: Thanks!!!!!


    I just got linux up and running and I am about to try my ppp connection - this could not have been more timely. I am a Unix C++ programmer - but modems/hardware etc - make me nervous.

    I do have one comment about one of your scripts (I dont mean to be critical) - but from a pure unix perspective the handling of the dynamic IP addressing is dangerous. On a standalone - you can get away with it but it is not good practice.       localhost
    $IP                MyMachine" > /etc/hosts

    I would change this to identify the line containing and modify it for the new IP address. This is easy to do in perl - or a dirty way would be to do something like the following:

    grep -v  /etc/hosts > /tmp/etc.hosts
    echo $IP   >> /tmp/etc.hosts
    cp /etc/hosts /etc/hosts.bak
    cp /tmp/etc.hosts /etc/hosts

    The other issue is that of permissions root should own /etc/hosts and for general setup I think you are relying on a loose permision structure - or you are running everything as root. It is safer to have a script which runs as root (a setuid script) to do this type of processing.

    Thanks for all your work - dont mind my 2 cents :->.


    Adam Schlesinger
    work phone:                                              (212)762-2289

    [Actually, I really DO appreciate Adam's 2 cents... His point is well taken and I wanted to include it here to make a point. It's true that I still do a lot of messing around on my system as root. This is admittedly not a very good idea and I'm slowly moving away from this habit, especially after dinging myself a couple times.

    Because I use Linux on my home PC, a standalone system, and I'm the ONLY one that uses it (my beloved wife is very supportive, but not exactly interested in learning UN*X) I do take liberties that could not be taken in other settings.

    This goes not only for the PPP scripts I've provided but for many of the suggestions I've made. I'm not security oriented, at least not at the moment, and so it's up to you to make sure your system is secure if you are in a multi-user environment.

    Caveat emptor -- John]

    .hushlogin suggestion by Jeff Bauer

    Date: Thu, 09 Nov 1995 22:20:42 CST
    From: Jeff Bauer <>
    To: <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: hushlogin tip

    Just wanted to say that I admire your Linux Gazette. One suggestion on your hushlogin tip.

    change: touch .hushlogin -->>> touch ~/.hushlogin

    This ensures that it gets put in the user's home directory. You might also mention that .hushlogin is extremely useful for automated logins (uucp, slip/ppp, expect) where the outpouring of free text may jangle the login script. This feature is indispensible for a pen-based application we use with the Apple Newton.

    Kind regards.

    <> Jeff Bauer                           Okay, I'm on the Internet.  <>
    <> Medical Support Services, Inc.       Now where's the money?      <>

    [Many thanks to Jeff for setting this straight! --John]

    Follow-up on traps and clearing the screen at logout by GarrettZilla :-)

    Date: Sat, 04 Nov 1995 23:30:02 CST
    Sender: <>
    From: GarrettZilla <>
    To: <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: On using trap to clear the screen at exit time

    Although setting up traps to catch the shell exit and clear the screen is an excellent way to do it (I use it at work where I have to use Korn shell), there is an easier way in bash: simply put the command into file .bash_logout. This file gets sourced when the login shell exits. This feature was copied from the C shell, where the file is called .logout.

    Setting up a trap is how to do it in Bourne or Korn shell, though - and so if you are sticking to that subset and worried about backward compatibility, you should probably should go that way.


    [I appreciate Garrett's note about using traps and .logout files. I'm afraid that I have little experience using shells besides BASH and welcome input on matters that I admittedly know little about. BASH is a very cool shell that has a LOT of power. It's definitely a candidate for the 'ol "man bash | col -b > bash.txt" trick... --John]

    And now for all you hardcore DOS converts...

    Jed and Joe testimonials by Eric Hultin and Jeppe Sigbrandt

    Date: Mon, 23 Oct 1995 17:06:21 CDT
    From: Eric Hultin <>
    To: <>
    Subject: Linux Gazette

    I really like the gazette (I didn't know some of the little tips you described) keep up the good work. I would like to give a little plug for one of my favorite editors: jed

    Why do I like jed? Well glad you asked, jed is a really cool editor that colorizes the various files you edit. (You have to make sure the file /usr/lib/jed/lib/jed.rc defines USE_ANSI_COLORS = 1;) You can set the colors used in colorcoding later in the file. The c mode which colorizes c code is invaluable, and the editor also colorizes other files such as .html and .tex files to improve readability. Since I program a lot and learned c by messing around with some code this editor was a real help to learning c IMHO, check it out and see what you think. (It's on the AP series on the slackware distributions.)

    Eric Hultin  x1373   | "Doctor's mistakes you bury,      |  Engineer's mistakes you live with forever."
    Undergraduate MechE  | A.K.A. Atilla => telnet 6789
    "Frustration has taken it's control"- via Pantera my opinion of ME205

    Date: Sun, 29 Oct 1995 20:10:18 CST
    From: Jeppe Sigbrandt <>
    To: <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: vi ?? Heck no !!!!!!!!

    Hi again,

    I've modified a line I remember reading in the gazette earlier on: If you have to use vi use vim If you have to use vim use jove If you have to use jove use joe

    Joe is the business. I discovered it today and nearly murdered the vi afficionado who assured me vi could do everything and was great. In 3 seconds I felt happy using it.

    my cshrc file now looks like this:

    	alias "vi"   joe
    	alias "vim"  joe
    	alias "jove" joe
    	alias "edit" joe


    ps: take this email with a grain of salt. I've only used joe for three seconds. But that was enough for someone brought up on dos edit !!!

    tip: try going into help screen. You'll see most commands are preceded by ctrl+k. Do ctrl+k + r to insert a file. It'll ask for a name. You won't know any. press tab tab, use the cursor to navigate in the directory structure and select a file. Couldn't be easier or more intuitive. Well, OK why do they use an 'r' to open and insert a file ?

    [I really appreciated these guys writing because it is a great reminder about preferences! :-) Great Jehads have been started, fanned by the undying zeal of adherents to particulars OS's, programs, and ways of doing things. Face it... I happen to like VIM and I'm pretty sold on this little prog, as much because I've gotten used to it and can do things pretty quickly on it now. For Eric and Jeppe, Joe and Jed were the ticket...

    Cool thing about Linux... you've got a pretty rich offering of stuff to play with. Explore and enjoy! --John]

    urlget clarification by Jack Lund

    Date: Wed, 22 Nov 1995 10:01:12 CST
    Sender: <>
    From: Jack Lund <>
    To: <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: url_get and Perl

    Hi there.

    One of your avid readers pointed me to your excellent online magazine, which, lo and behold, had a letter about my url_get script. I'm really glad that everyone seems to find it useful, and especially glad to hear that it works well on Linux.

    I *did* want to clear up one tiny misunderstanding - url_get *should* work equally well under Perl 4 (specifically 4.036) and Perl 5 (you had mentioned that you haven't tried it yet because you haven't upgraded to 5.001 yet).

    Anyway, thanks much for the blurb and kudos, and congratulations on an excellent magazine.

    Jack Lund                     "The dead have risen from the grave,
    Graphics Services              and they're voting REPUBLICAN!!!"
    UT Austin Computation Center                         -Bart Simpson     www:

    [Many thanks to Jack for taking the time to write a note and clarify this! Hopefully, now that the LG is being mirrored at a couple different locations, getting a connection isn't as hard as it was in September. Still, give Jack's prog a whirl and if you like it, drop him a note of thanks! --John]

    xwininfo tip by Jason Lewis

    Date: Fri, 10 Nov 1995 02:18:05 CST
    From: <>
    To: <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: linux gazette


    I just wanted to tell you that i think the Linux Gazette is really cool. I like your style of writing, it brings the material to life :)

    Anyway, i just wondered if you knew of this program called xwininfo.

    If you run it, then click on a window, it prints up lots of info about that window. One of the interesting bits of info is a geometry command to get a window exaclty like that (perfect for cutting and pasting into .fvwmrc or something)

    Thanks alot for the work you put into the Gazette.



    Date: Sat, 11 Nov 1995 16:56:49 CST
    From: Jason Lewis 932535 <>
    To: John M. Fisk <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: RE: linux gazette


    On Fri, 10 Nov 1995, John M. Fisk wrote:

    > Thanks for the note!  Yup... I've messed around a _little_ with this
    > and you're right... you get GOBS of interesting info :-)  I'm not
    > quite wizardly enough to fully make use of it but it is kinda fun!
    > thanks for the suggestion!

    No worries, the most interesting thing for me is that i can resize and position a window where i want it, then i can use xwininfo to get the geometry command required to get a window in that place and of that size. I don't have to think about it. i can just cut and paste the geometry info straigh into the relevant line.

    Anyway, seeya later.


    /Jason Lewis - System Administrator for ucnet -\
    | Be alert. Be vigilant. Behave!                                              |
    \ __________________________________________________/

    [This is yet another handy suggestion for making your ~/.fvwmrc tinkering just a little easier. Getting your program windows just the right size is one of those things that makes life a LOT easier and makes your desktop a lot more functional. I tried Jason's tip and it really is pretty easy to use. Just open up you favorite editor with your ~/.fvwmrc or system.fvwmrc file, arrange your desktop the way you want it to look, and then run xwininfo in an xterm. You can repeatedly fire it up, click on each window, get the information about its geometry, and then paste the numbers right into your fvwmrc file. Very handy! -- John]

    Offline Web page viewing tip!

    Date: Thu, 16 Nov 1995 23:12:54 CST
    From: <>
    To: John Fisk <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: Linix-Gazette...2 cent tips!

    Just a 2 cent note to add to your collection. I'm hurrying to send this as it seems most Linux'ers have similar realizations to common problems. One of the easiest ways to save money on 'ppp' connect time is to save all your long web pages and then read them Off-Line.(Linux-gazette-Oct)

    If you want to save even more effort, save the files in SOURCE mode and then it is possible to use any links for further browsing. To do this, I used the NCSA httpd_1.3 server availible on / (Actually, it is on the Infomagic CD, a newer version is on Sunsite) The directions can be read with a text editor (they are in http source format). After installation, the web browser will 'see' your saved html files in <http://localhost/...> where the indexing feature of Netscape can access all files in the httpd DocumentRoot directory and access your home page. My homepage is just an edited copy of the best bookmarks I have found and by backspacing over the 'Welcome.html' to <DocumentRoot> I can load any html document and follow the hard links. This makes a 3Meg homepage realistic!

    This is an example of the 'BEST' of Linux. By having access to a wealth of features, I can chose the software and mode of operation I want. I tried to use Eudora for mail (with WIN) but never had the warm fuzzies. At least LINUX will hang up my modem without having to cycle power or pull the plug.

    I think I have an appreciation for the development of LINUX as a bootstrap operation. Just learning 'UNIX' administration was a convoluted task, O'Reilly Books has made a lot of money on me.

    I really enjoy your gazette, it will be a long time before I have all the software I want. I'm trying 'CALDERA' but seem to have one foot firmly planted on the command line. Bye for now.

    |Disclaimer: Opinions expressed are my own, and   | Do the neoLudites have |
    |should be taken with a grain of NaCl, EVEN by me.| a Home Page Yet ?      |

    [Here's an interesting suggestion for all you budding WebMeisters out there. I've started doing somthing similar to this only on a bit more simplistic level: for web pages that I've wanted to save I merely save them as Source and then use Netscape's R mouse button menu to save the image as well. Presto! instant webpage. I've then put them all in the same directory and created a bookmark entry for this directory. Now, to view the pages even when I'm not "online" I just fire up Netscape, ignore the error messages, and use the bookmark to get to the directory listing. --John]

    Ooops!! :-( Thanks for catching these mistakes -- Frank and Boaz Studnitzky

    Date: Tue, 28 Nov 1995 10:03:01 CST
    From: <>
    To: <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: Missing <a>

    Hi John!

    There is a <a> missing in the October Linux Gazette.

    The position is in the top line.


    Bye, Frank.

    Date: Wed, 29 Nov 1995 10:19:09 CST
    Sender: <>
    From: Studnitzky Boaz <>
    To: <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: A small typo bug (wrong address)

    Check out your link to It actually points to


    [And finally... many thanks to these guys, (and admittedly a few others as well :-), who wrote to inform of my butter-fingered foul-ups. Thanks to all who've caught these things and let me know about them. Cheers! --John]

    An Intro to DOSEMU by Alan Bailward

    An intro to DOSEMU

    Running DOS programs under Linux

    In the following, I will try to make sense of several issues:

    What and Why

    First things first. You can run DOOM under it .

    DOSEMU is a user program that allows the Linux kernel to run MS-DOS in a "DOS box". This is basically a "virtual machine" - that belives that it is alone on the computer, and has full control of the hardware and software.

    To the software this does not seem to mean much. The DOS program Terminate can tell it is being run in a virtual machine, and 'msd' and 'mft' give some interesting results. On the whole though, programs don't seem NOT to work because they are running under a DOS Emulator.

    What Will Work

    Although I don't use DOSEMU to run a lot of DOS programs, I have had good luck with the ones I have tried. Your milage may vary.

    Your best indication is the file EMUsuccess.txt. This gives a list of the many DOS programs that currently run perfectly, or very close. The programs include games, utilities, and "real" programs. I will also tell you that Windows 3.1 will run under DOSEMU. This requires patching your kernel, and doing some other funky stuff - all available in the DOSEMU-Win3.1-HOWTO file.

    Generally I have found that the little programs work. EDIT, 4dos, arj, pkzip and such work without a hitch. I have had occasional problems with CSHOW, and althought I can use TERMINATE - it reports a 14.4 connection, but it is definately NOT going at over 1200! Telemate 4.20 was a little better. You will notice that for everything there is a little delay. My 486-33 would seem to be a 386-40, or a 486-25, depending on the program.

    My real "DOS" is Windows 95, btw, and DOSEMU has no problem with it. (gee, I wonder how that can happen - isn't it a whole NEW OS? ).


    At this time (Nov 1, 1995), the latest version of a "stable" DOSEMU is 0.60.3 This requires at least Linux 1.1.43. You can ftp the latest version of DOSEMU from or or For the non-faint of heart, poke in the /Development sub-directory.


    RTFM! No, really!! The Quickstart.txt (included in the DOSEMU .tgz file), is excellent, and is probably your best bet for a worry free setup. What I would suggest is to look in section 2 of the DOSEMU-HOWTO file. This tells you how to speed up compiling, and a few other helpful hints.

    If you have a CDROM - take a look in the ./dosemu0.60.4/drivers/cdrom.c file. There is a flag that you have to set to allow the CDROM to recognize the (included) program 'eject'. If you don't have this flag set to 1, and use the 'eject' program, DOSEMU will not recognize when the CD has been changed, and this will really screw you up :)

    Also note that when you setup DOSEMU's access to your other drives (below), you are still running out of UNIX. If you have your DOS drives mounted as 744 (-rwxr--r--), this will apply to DOSEMU as well! If you are logged in a a non-root user, and trying to run program that writes to a log file, creates temporary files or whatever - DOS will report that it "can't open file" or whatever. I have mine mounted like this - and it is inconveniant, but (IMHO), safer.

    Other stuff

    Ok, the rest of this are just my babbling on. Problems, sucesses etc for my own DOSEMU OONE (Off Of Net Experiance).

    In the 'dosemu.conf' file, you can define a whole slew of parameters... amount of memory, EMS, XMS conventional, mouse, com ports etc. All of this is well documented within the file, and examples are given. If you don't understand a setting, do exactly what any self-respecting Linux hacker would do... play with it. Or just leave it alone, and hope .

    Because DOSEMU does grab control of the COM ports, you will find that if you start it up, then switch to another VT and try to dial out with minicom or DIP, that the modem is locked by DOSEMU. You can either not allow DOSEMU to look at the COM ports at all, or start your modem program before you start up DOSEMU. If you do the latter you will find a message on the screen when you exit DOSEMU that it couldn't get at the modem.

    You will more 'n likely set DOSEMU to boot up on the HD-image file. This is an image of a drive, that DOSEMU uses as a boot drive. It is where you put the, msdos.sys, autoexec.bat, and config.sys files. Basically you pretend that it is your C: and you go from there.

    This will be your 'C:'. You can use the 'lredir' program to setup other drives, so that DOSEMU can recognize them. You do this by invoking something like:

    C:\> lredir d: LINUXS\dosd

    This will mount the directory /dosd as DOSEMU's D:

    I have not found a way to get my "real" C: (mounted as /dosc), to become DOSEMU's C:. This would allow my batch files and stuff from the bygone era of DOS to work properly. As it is, I have the following set on my computer:

    REALITY         LINUX           DOSEMU
    -------         -----           ------
    /hdimage        /hdimage        C:
    C:              /dosc           H:
    D:              /dosd           D:
    E:              /dose           E:
    Linux Root      /               F:
    CDROM           /dev/cdrom      G:
    As you can see it is a little screwy. But it allows my to access all the data on my computers hard drives.

    You should note that by default, DOSEMU does not recognize more that C: and D:. If you try to go beyond that you will get the error that there are not enough drives. I use the program LASTDRV.COM (that came with Quarterdeck's QEMM) to make DOSEMU give me all the drives I want.

    It also comes with another program called xdos. This is exactly what you think it is. Although you can start up DOSEMU in an xterm or something similar, the xdos program starts it up in it's own little box, with a more "correct" looking font :) I have found though, that graphics programs will cause problems under xdos.

    In conclusion

    DOSEMU is an excellent program. It will allow a vast majority of DOS programs to run under Linux. It is, however, still just a DOS emulator. Which means that programs will NOT run as fast under it as they would under native DOS. They come close though, and DOSEMU gets better all the time.

    I just want to thank John M. Fisk for the opportunity to contribute to the Linux community, and to the DOSEMU team, for a great program (and I hope I didn't screw up too bad anywhere in this artical). Happy Linuxing!!

    Alan Bailward (now URLed!)

    [This article, and the one following on Garrot, were very kindly submitted by Alan Bailward. I owe a HUGE debt of gratitude for his work on these articles. By all means, if you've appreciated his work or if you have comments or suggestions please drop Alan a note. Thanks! --John]

    An Introduction to Garrot by Alan Bailward


    What and HOW

    What you will notice while running DOSEMU, is that your load average will go up, and your memory will go down. This is because while DOSEMU is running, it is still sucking up your system resources (as DOS always seems to do ). The way to get around this is to run a small program called GARROT . GARROT should be available in the dosemu sub-directory at your favorite Linux FTP site.

    What GARROT will do is:

    [...] improve Linux performance by coercing the operating system running inside of DOSEMU to release the CPU back to the main system during idle periods.

    GARROT runs as a TSR inside the DOSEMU session, so installation is simple, especially since the .tgz file comes with the binary! All that I did was make a sub-directory off of my DOSEMU's C: drive and put something similar to the following line in my AUTOEXEC.BAT:

    lh c:?rrot?rrot -8
    The number is an argument that the author has dubbed the "garrot constant".

    The "garrot constant"?

    The numeric argument gives the best balance of CPU time given to DOSEMU. You are supposed to set it at approximately one-half of your Linux BogoMips value. So if your BogoMips are 16.7 (like mine), you would start GARROT with the argument as 8 or 9.

    [NOTE: I am using kernel 1.3.30, and the BogoMips no longer show up when I boot up. If you have a kernel that does this, and you don't remember the value from an earlier kernel, check out the BogoMips mini-HOWTO (available in the linux/docs sudirecory of any self-respecting FTP site). This has examples of what the BogoMips should be for x86 processers.]

    The proof is in the TOP

    The author of GARROT recommends that you can tell if the "garrot constant" is working or not by running 'top'. Start up DOSEMU (without garrot) in one virtual terminal, and 'top' in another. Note the CPU useage by the program 'dos' in top. When you are looking at the VT with 'top', DOSEMU is idle, and should not be taking up the CPU that it is (44.1% in my case). Now edit the AUTOEXEC.BAT file and put the line with garrot in there. Then exit DOSEMU and restart it.

    [Another note: I just found out that if you run garrot from the dos prompt within DOSEMU, it will 'take a guess' as to the correct level (level = constant)]

    Now when you look at the VT with 'top' running, you should see that the CPU taken up by the 'dos' entry should be way down (in my case from 1.0 to 0.1). You can play with the "garrot constant" to get the best mix of performance in and out of DOSEMU.

    Alan Bailward (now URLed!)

    [After Alan wrote the above article on DOSEMU he came through once again with this sister article on the program Garrot. Please drop this guy a note and tell him THANKS for the work that went into this! I'm absolutely serious when I say that the Linux Gazette was never meant to be a one man act. I've started this as a means of SHARING ideas and information and I really appreciate Alan's hard work on this. --John]

    Building a Better hack script by Ross J. Michaels

    Date: Mon, 16 Oct 1995 08:09:06 CDT
    From: System Administrator <>
    To: <>
    Subject: Linux Gazette

    Here's a little something I whipped up. Thought you might be interested...

    #	Ross J. Micheals (1995)
    #	Distribute freely as long as no changes are made without my thumbs up
    #	Version 1.0
    #	Based upon an idea by Linux Gazette Author John M. Fisk (thanks!)
    #	This program is designed to make the control of multiple configuration
    #	files just a bit easier.  (Ok, a _lot_ bit.)
    #	Syntax
    #	----------------------------------------------------------------
    #	hack *filename*
    #	(Wildcards not tested yet!)
    #	where the user is ROOT
    #	and the *filename* is your standard text file
    #	This program will
    #	----------------------------------------------------------------
    #	1. Create /root/links and /root/config_dist if you don't have
    #	   them already	
    #	2. Make a copy of *filename* and save it in $DIR_DIST as 
    #	   *filename.dist*.  If the mirror of the distribution file
    #	   already exists, do not make another.
    #	3. Create a symbolic link in $DIR_LINKS to *filename*.  This way
    #	   you can call upon a particular filename a tad easier, and you
    #	   will also have a nice list of all the configuration files that
    #	   you have changed!  (Great for backups and upgrades)
    #	4. Fire up the editor *filename*.  I think that's it.
    # 	Location where you want to put the copies of the distribution files
    # 	Location where you want symbolic links to all of the configuration 
    #	files that you have changed
    # 	Default editor
    # 	Current directory
    #	 Make sure user is logged in as root
    if [ "$LOGNAME" != "root" ]
    	echo "hack: user not logged in as root"
    	exit 1
    # 	Make sure the user typed in a filename to *hack*
    if [ "$1" = "" ]
    	echo "hack: filename is missing"
    	exit 2
    # 	Make sure the filename to *hack* is a real file
    if [ ! -f "$1" ]
    	echo "hack: filename is bad or is a directory"
    	exit 3
    BASENAME=`basename $1`
    # 	Create $DIR_DIST and $DIR_LINKS if it does not exist already
    if [ ! -d $DIR_DIST ]
    	echo "hack:" $DIR_DIST "not found"
    	echo "hack: creating" $DIR_DIST
    	mkdir $DIR_DIST
    	chmod 711 $DIR_DIST
    if [ ! -d $DIR_LINKS ]
    	echo "hack:" $DIR_LINKS "not found"
    	echo "hack: creating" $DIR_LINKS
    	mkdir $DIR_LINKS
    	chmod 711 $DIR_LINKS
    #	Create the backup file (finally!)
    if [ ! -f "$DIR_DIST/$BASENAME.dist" ] 
    	cp $1 $DIR_DIST/$BASENAME.dist
    	echo "hack: creating file" $DIR_DIST/$BASENAME".dist"
    elif [ -f $DIR_DIST/$BASENAME.dist ]
    	echo "hack:" $DIR_DIST/$BASENAME".dist already exists"
    	echo "hack: fatal error in destination file"
    	exit 4
    #	Create the symlink
    if [ -f $CURR_DIR/$1 ]
    	if [ $CURR_DIR = "/" ]
    		ln -s "$1" "$DIR_LINKS/$BASENAME"
    		echo "hack: linking" $1
    	elif [ ! -L $DIR_LINKS/$1 ]
    		ln -s "$CURR_DIR/$1" "$DIR_LINKS/$1"
    		echo "hack: (c) linking" $CURR_DIR"/"$1
    elif [ -f $1 ]
    	if [ ! -L $DIR_LINKS/$BASENAME ]
    		ln -s "$1" "$DIR_LINKS/$BASENAME"
    		echo "hack: linking" $1
    	echo "hack: something is fundametally wrong here"
    $EDITOR $1

    Feel free to include it in the next version of Linux Gazette. I am also working on a small routine to check whether you used wild-cards or not, if you want to wait for that relase. But, it seems to work pretty well as is. Thank you so much for your enthusiasm.

    Ross J. Michaels <>

    [A couple editions ago I made the suggestion that, in order to save one's sanity, important system files, and probably one's... uh... derriere... :-), you could save your original system config files using a shell script like "hack". This was, admittedly, the merest skeleton of a program and was meant more as a suggestion than a full-blown program.

    Well, several folks wrote back with MAJOR improvements and suggestions. I want to thank these folks who include:

    What's so important about archiving all this stuff...? Well, you have only to have a system crash or inadvertently delete/overwrite one of these files to set you back HOURS of hard work. By all means do yourself a favor and save your hard work! ;-) Also, keeping backups of all your system files lets you tinker with a BIT of a parachute... if something gets totally whacked out, you can retrace your steps. A pretty good caveat to keep in mind is:


    If you make changes, always give yourself a means of backing out completely and restoring things to their original state. Practice safe LinuX! :-)

    While you can implement a plan to save config files at ANY time, it's probably ideal to do so when you're planning a system upgrade or reinstall. I think you'll be impressed by the creativity and the thoughtfulness of the ideas shared by these folks.

    Please keep in mind that this and all material presented here is copyrighted by its respective authors. If you modify any of these programs and wish to make it publicly available, please contact the author. Most of all, enjoy! -- John]

    Building Another Great hack script by Judith Elaine

    Date: Mon, 16 Oct 1995 19:47:49 CDT
    From: Judith Elaine <>
    To: <>
    Subject: linux program date

    Dear John,

    Well, I'm sitting here skimming through the August and September copies of the Linux Gazette as i download software i've been saving at work -- an 8 Meg tarred and compressed file.

    I had taken your suggestion to write a backup script to heart last night and wrote not only a script like your "hack," which so neatly stores the original distribution, but also a program to save my modifications.

    ------------------------------- CUT HERE ------------------------------
    # /usr/local/bin/savemod  -- in the spirit of safehack
    # Copyright (c) 1995 Judith Elaine
    \cp $1 $DIR/$1.`date +%d%h%y`
    echo " " >> $DIR/$1.`date +%d%h%y`
    echo "#>> "$PWD/$1" copied over on "`date` >> $DIR/$1.`date +%d%h%y`
    echo Made a backup of $1.
    ------------------------------- CUT HERE ------------------------------

    You'll note i use the "date" program and a technique called command substitution, or something like that. I'm sure with some fiddling around and reading the man page you'll figure out the important points about date.

    I'm using it here in several interesting (to me at least -- it's how i sort out all my data analysis at work!) ways. First, i copy the file i want to save to the "safe" directory and give it the same name PLUS the date of the transfer. While i can find out useful last modification times with ls, i can't archive multiple versions unless i give them unique names. This automatically does that. (I suppose, if you change files a lot during the day, you might want to append the hour and minute, as well.) Thus, the invocation

    # cp h h.`date +%d%h%y`

    copies the file h to one with today's date appended at the end:

    # ls h*
    h          h.16Oct95

    The second way i use date is to add a comment line at the very end of the file which notes the path of the original file ($PWD/$1 could admittedly be a roundabout path, but it'll still make sense) and, redundantly the date of the backup. I suppose i could add a line which would append the file name to a backup tarring list, as you suggest we keep in the August issue.


    Just about halfway through the 8 Meg....

    Thanks again for an EXCELLENT resource!


    Judith Elaine <>

    [Boy... my "thank you" list just keeps getting long and longer... :-) Sincerest thanks and kudos go to Judith Elaine for kindly submitting this version of the hack script program. As you can see by the Date: field, both Judith and Ross wrote at almost identical dates confirming something I've suspected for quite some time... great minds not only think alike, but synchronously as well! :-) After you've messed around with these scripts drop Judith and Ross a note of thanks! --John]

    RCS: Managing System Config Files by Nick LeRoy

    Date: Tue, 07 Nov 1995 14:42:15 CST
    From: Nicholas R LeRoy <>
    To: <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: Linux Gazette


    Sent you some e-mail a while back about the Linux Gazette, and here's another tip probably worth publishing. I haven't searched through all issues yet, but I don't see it in there. If it is, sorry...

    In your July issue, you describe copying files to /config_dist or such for back-up purposes. Such a mechanism is useful, indeed, but I believe that there is a *better* solution: RCS. Install the RCS package, and let RCS store *all* your previous versions. This allows you to store a change history, change description, etc. with all files. With RCS you can ask: What did I change to my hosts file? I had an old version of that worked, and now its broken. What's changed? I solved this problem once before. How? Etc.

    Oh. RCS stands for Revision Control System, and is GNU software.

    Here's a brief summary on the use of RCS. Pretend that the file you want to manage is '/directory/file'.

    1. Obtain and install.
      Probably should do: man rcsintro for an introduction

    2. To put a file under revision control:
      cd /directory
      mkdir RCS (not required, but recomended.)
      ci -u file Puts the file under revision control.
      answer questions Describe the file to RCS.
      Note that file is now r--r--r-- (read only).

    3. To Check out a file:
      co -l file Checks out the file (now writable).
      You may now modify the file.

    4. When done, check it back in:
      ci -u file (Will ask your for change description)
      description_of_changes (Describe what you did to the file).
      (File is now r--r--r-- again).

    5. To get a log of the file:
      rlog file
    6. To find differences between current and last checked in:
      rcsdiff file

    Many more things. Do read the man page. Its worth the effort to learn!

    -- Nicholas R. LeRoy <>

    | /`-_     Nicholas R LeRoy            | Linux -- What *nix was meant to be. |
    |{     }/   | gcc   -- What C was meant to be.    |
    | \ *  /   Norland Corp                +-------------------------------------+
    | |___|    W6340 Hackbarth Rd          |  Escape the Gates of Hell with      |
    |          Fort Atkinson, WI 53530     |   The choice of a GNU generation... |
    | Hey -- These are my own ideas, not my employer's.  Don't blame them...     |
    [Nick's suggestion was one of those "slap-your-forehead-for-not-thinking-of-this" kind of ideas. I'd been using RCS for keeping track of the various programming assignments I'd been working on at school. Using RCS for managing system configuration files is an excellent idea and is a powerful method of keeping track of various CHANGES you've made along the way. Nick is VERY right... RCS is definitely worth the effort to learn! --John]

    Supermount: Mounting Floppies the VERY Easy Way by Daniel Sully

    Date: Sat, 04 Nov 1995 23:54:50 CST
    From: Daniel Sully <>
    To: <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: Neato linux util, and aliases

    Hi there.. I've read all of your Linux Gazette issues, and think that you are doing a great job! TLG, gives tips and neat little things that say the O'Rielly books, or the LDP won't have, and i think that is a big draw..

    2) I may be able to mirror the LG site.. but first just wondering, all of the notices about your site being overloaded.. what type of hardware/bandwidth do you have to be overloaded? I don't want to bog down my system too much =) I am on a full T1 with a 80Mhz DX2 linux box, for web serving..

    c) For TLG: check out the supermount patches, available at:

    it's a kernel patch that allows dynamic mounting of floppy and cdrom drives..

    you just add a little to your /etc/fstab file, recompile the kernel, and then, you can put a disk in the drive, cd /floppy and it mounts if for you. You can even remove the disk, and it will auto umount..

    AND.. for the 100 door prize.. for all the DOS converts, (most of us)

    in ~/.bash_profile

    alias a:='cd /floppya'
    alias b:='cd /floppyb'
    alias c:='cd /dosc'
    alias d:='cd /dosd'
    alias e:='cd /cdrom'

    pretty cool huh? I think so... =)

    Thanks for your time.

    Daniel Sully
    .sig got eaten

    And in reply to my question about mounting floppies read/write:

    Date: Mon, 06 Nov 1995 11:13:53 CST
    From: Daniel Sully <>
    To: John M. Fisk <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: RE: Neato linux util, and aliases

    No, I mount my floppies as

    / /floppya	supermount	rw,dev=/dev/fd0

    in my fstab file... thats it.


    On Mon, 6 Nov 1995, John M. Fisk wrote:

    > Dan, I managed to get my hands on a copy of supermount and recompiled
    > my kernel -- no trouble at all.  I haven't played with it yet, but in
    > looking over the docs noticed that you need to mount devices read only.
    > Has this been a problem at all for you?  CD's would obviously be read
    > only, but floppies are often used for BOTH read and write op's, at
    > least I use mine for that... I keep a lot of stuff archived to floppy
    > to save on HD space and routinely cp to and from floppies... how do
    > you get around this?

    And for those of you who are interested...

    Yup! After a bit of tinkering and a kernel recompile, supermount is up and running on FiskHaus and it seems to be working great! If you're an old DOS convert who's forever forgetting to "umount" those floppies then you'll definitely want to give this thing a whirl.

    FYI... I'm using kernel 1.2.13 and the supermount-0.4a.tar.gz file that can be found on and mirrors as listed above. If you're interested, here's what I found worked...

    But before we proceed, let me STRONGLY urge you to read the README that comes with this program. If you're doing your own Linux sysadmin then you need to know what's going on. I'll tell you what I did to get this thing working... it's up to you to make sure it'll work for your system.

    Caveat emptor...

    Basically, the steps are:

    1. unarchive the file and read the README's
    2. apply the kernel patch
    3. edit /etc/fstab
    4. reboot the system

    When you unarchive the file you'll find the files:

    The first file is the unified diff for the 1.2.13 kernel and the second is for the 1.3.30 kernel for all you "riding the ragged edge of destruction" kinda folks :-)

    Gunzip the one you need and cp it to your /usr/src directory. And in the spirit of "never fail to state the obvious..." it goes without saying that you'll need a FULL kernel source to work with and not simply the includes.

    After you've done this, to apply the patch simply enter:

    	patch -p0 < supermount-0.4a-1.2.13.ud
    	patch -p0 < supermount-0.4a-1.3.30.ud
    depending on which kernel you happen to be working with. You should see all kinds of groovy messages go whizzing by. (Make sure you're in the /usr/src directory when you try this little maneuver or else all those groovy little messages will be replaced by a "Hmmm... this does'nt seem to be working" kind of message.)

    Speed readers -- you'll need to read quickly here, don't worry about content.

    The rest of us will just hang out.

    Now, assuming that this went smoothly (if not... you're on your own Pilgrim...) You're ready to compile your new kernel. Since I've gone over this in the past, suffice it to say that all you'll need to do is simply:

    	make config && make dep && make clean &&
    	make zImage (or whatever you'd like)
    This will take you through the WHOLE process in one fell swoop (now where did THAT little turn of speech come from, I wonder... :-<> ). You could add a "make mrproper" to the front of all this mess. So, the double ampersands will let the process continue as long as there are no errors. If you've done the kernel compile thing before you should know how long this will take. For most of us, it's the bag 'o Nachos and Gilligan's Island reruns while this thing is cooking...

    Oh, before I forget... and just so that you don't end up wasting your time... :-) When you are doing the "make config" part you'll come across a line that asks you:

             Dynamic mounting of removable media?
    this is where you'll need to answer "y" to compile in supermount support.

    Once this is done, and your new kernel is compiled, DON'T FORGET TO RERUN LILO!! Believe me, I've had to reach for the boot disk more than once for forgetting to do this... ;-) save yourself the hassle!

    Now, all that's left to do is edit your fstab file. Again, a word of encouragement: DON'T BUGGER THIS THING UP!

    There, don't you feel affirmed?

    Ok, ok... seriously... keep a backup of the fstab file. You've already read three excellent suggestions in the articles above as to how to do this. Pick your weapon! At the very least, make a copy of it and call it something like "fstab.currently_working_version_that_I_promise_not_to_delete".

    Use your discretion.

    Now, once again: read the README! It'll tell you what you'll need to add for your system. Here's what mine happens to look like at the moment:

    #	file:	/etc/fstab
    # This sets up the various filesystems which can be mounted at boot up or
    #	manually.  First we'll set up the boot up filesystems:
    # device	mount		type	options		dump	fsck
    #-------	-----		----	-------		----	----
    /dev/hdb8	swap		swap	defaults	0	1
    /dev/hdb6	/		ext2	defaults	0	1
    /dev/hdb7	/usr/local	ext2	defaults	0	1
    none		/proc		proc	defaults	0	0
    /dev/hda2	/c		msdos	defaults	0	2
    /dev/hdb5	/f		msdos	defaults	0	2
    #/dev/hda5	/os2		hpfs	defaults	0	2
    # Now, set up the filesystems that can be manually mounted.  Use the option
    #	"noauto" to keep mount* from mounting the fs at bootup.
    # /dev/fd0H1440	/fd0	ext2	user,noauto	0	0
    # /dev/fd0H1440	/a	msdos	user,noauto	0	0
    /dev/sbpcd	/cdrom	iso9660	ro,noauto	0	0
    # Below, let's try using the "supermount" prog which has been compiled into
    # the kernel.
    /	/a	supermount	rw,fs=msdos,dev=/dev/fd0	0	0
    /	/fd0	supermount	rw,fs=ext2,dev=/dev/fd0		0	0
    As you probably will notice, I'm stretching the rules just a little bit by mounting the floppies for both the msdos and the ext2 filesystems as read AND write. DON'T DO THIS YOURSELF WITHOUT READING THE README FILE!

    ...well, unless you're the kind to run around with slippery pool on a hot day with scissors in your hand... ;-)

    Anyway, edit your fstab file, reboot the system, and you should be ready to play! First, however, you might want to check and see what "mount" tells you about your filesystems. Simply enter:

    and you should see something similar to this:
    /dev/hdb6 on / type ext2 (rw)
    /dev/hdb7 on /usr/local type ext2 (rw)
    none on /proc type proc (rw)
    /dev/hda2 on /c type msdos (rw)
    /dev/hdb5 on /f type msdos (rw)
    / on /a type supermount (rw,fs=msdos,dev=/dev/fd0)
    / on /fd0 type supermount (rw,fs=ext2,dev=/dev/fd0)
    The last two entries should look familiar! Now, if everything's set up OK then you're golden!

    You can now dispense with the "mount - umount" cycle each time you insert your floppies. Just pop one of those badboys in and command your system to:

    	ls -l /fd0
    When I do this now... yup, this is a live demonstration folks... Madam... please get your child back... please don't push or shove...

    When I type this in I get:

    total 1299
    -rw-r--r--   1 root     root       534714 May 31 14:46 mfm-stat-bin.tar.gz
    -rw-r--r--   1 root     root        67359 May 30 13:39 xcolorsel.tar.gz
    -rw-r--r--   1 root     root       230145 May 30 12:59 xfm-1.3.2.tar.gz
    -rw-r--r--   1 root     root       112640 May 31 14:49 xgoups-1.3.tar.gz
    -rw-r--r--   1 root     root        64204 Jan 20  1995 xinfo-1.01.tar.gz
    -rw-r--r--   1 root     root       297522 May  5  1995 xkeycaps-2.28.tar.gz
    -rw-r--r--   1 root     root        11256 May 30 15:25 xvset-0.90.tar.gz
    for one of my archive disks.

    Notice, I didn't have to "mount" anything before doing this and I won't have to "umount" anything when I'm done. No smoke, no mirrors, and my fingers never leave my hand... :-)

    You get the point... go out and enjoy!

    [Addendum: Supermount is designed to work with BOTH floppies and CDROM's. However, after a lot of tinkering around, I wasn't able to get the CDROM support to work correctly. It worked correctly only with the first CD that was inserted, thereafter it didn't appear to recognize a media change and would not ls or cd correctly after changing CD's. Now... this DOESN'T mean that it doesn't work, it only means that I couldnt' get it to work on my system.

    As a kludge, I found that if I manually "umount'd" and remounted /cdrom that things worked OK, but this sort of defeated the purpose of using it.

    Because of this, I'll leave it up to you to play around with it. The README file describes what you'll need to do to include CDROM support (hint: ro,fs=iso9660,dev=/dev/cdrom). If you get it working, drop me a note... I'm using a stock Creative Labs SB16 Card and the Creative 2X IDE CDROM drive attached to the SB16 card. If you get it working, let me know what your hardware setup is.

    Thanks! --John]

    Logging with Inittab by Eric Sorton

    Date: Sun, 22 Oct 1995 01:31:27 CDT
    From: <>
    To: John M. Fisk <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: RE: Linux Gazette

    > I've had several requests for information about the "init" program
    > and a comparison between the SysV style and the "other style ?"
    > (I'm sorry, I really can't recall at 5:30 am what the other one is)
    [the "other style" is BSD :-) --John]
    > Anyway, there have been a couple questions about this and how to
    > make effective use of init.
    > If that falls within the realm of your expertise then any ideas,
    > suggestions, or instructions as to how best to use it would be
    > quite helpful!

    I'm somewhat familiar with BSD style (I admin SunOS 4.1.? for the school) and I've used Slackware, which is BSD, for about a year. I've just installed RedHat, which is SYSV and am currently trying to unwind that ball of yarn. Although I can tell the difference between the two, I can't do much else. So, I'm not much of an expert and wouldn't feel comfortable talking about a subject I don't know much about.

    Here's a tip if you can fit it in somewhere ... It deals with the inittab file. I needed/wanted to display a log file to a VT ... I'd seen people do it using syslog and redirecting syslog to the VT (ask me and I'll explain), but my log file didn't go through syslog. I came up with this solution.

    Put the following line in your initab:

    c7:45:respawn:/usr/bin/tail -f /var/adm/log.smb >> /dev/tty7

    Here's a short explination of the fields:

    Hope that is clear, its a little rough, but I believe it will get the point across. Feel free to clean it up and put it in the Gazette, I've found it to be a useful tip.

    /-=-=-=-=-=-=-=-=-=-=-<<< ERIC F SORTON >>>-=-=-=-=-=-=-=-=-=-=-\
    | -- Embry Riddle Aeronautical University    |
    | Graduate Administrator Aerospace Engineering Computer Systems |
    |	Phone: (904) 226-6752		Office: E&T 208		|
    |  Certainly the game is rigged.  Don't let that stop you;      |
    |        if you don't bet, you can't win.      --RAH            |
    \-=-=-=-=-=-=<<<  HTTP://ERAU.DB.ERAU.EDU/~ERIC/ >>>=-=-=-=-=-=-/

    Logging messages to files & the console...

    The full details of using syslog for system error logging are a bit more than I want to get into at the moment. However, Eric did bring up an issue that is probably worth mentioning here: printing system messages to both file and screen.

    BSD-style error logging, as is frequently used with various Linux distributions, utilizes the syslog daemon to route system and error messages from various processes and programs and write them to a specified output. This facility is available for quite a few processes including printing, mail, the kernel, login authentication, and so forth. For those of you who've set up PPP and used the README that comes with the ppp-2.1.2[x] distribution you've read the suggestions regarding setting up error logging.

    Again, not to go into a full blown discussion of error logging... it is possible to have syslog write system messages to both file and console by including an entry for the process you want in /etc/syslog.conf.

    Using the PPP setup example: error logging for PPP is provided by including:

    local2.*                                        /var/adm/ppplog
    local2.*                                        /dev/console
    in your /etc/syslog.conf file.

    The thing to point out is that there are two entries for the "local2.*" logging facility. The first logs the output to the usual administrative logging file /var/adm/ppplog. Obviously, you can specify any filename you wish for this purpose. The next line also logs the output of "local2.*" but this time sends it to /dev/console -- your screen! By including dual stanzas for both file and console output you can log messages to multiple outputs.

    For an enjoyable and very enlightening discussison of the various aspects of system administration I'd highly recommend to you the book:

    Essential System Administration, Second Edition by Aeleen Frisch
    Pub: O'Reilly, ISDN: 1-56592-127-5

    Aeleen Frisch is a marvelous writer with a wealth of practical experience. She writes in a task-oriented fashion that provides information about how to get things done as well as how things work! This second edition also includes a number of sections devoted to Linux, as well as the other popular commercial UNIX iterations.

    This is definitely one of those books to put on your Christmas List...!


    More Setterm Fun by Gary Jaffe

    Date: Sun, 05 Nov 1995 21:05:00 CST
    Sender: <>
    From: Gary Jaffe <>
    To: <fiskjm@ctrvax.Vanderbilt.Edu>
    Subject: setterm suggestion

    John --

    I love reading your tips on Linux. I particularly enjoyed the article on setterm. You suggested adding the following to your ~/.bash_profile

    case "$V_TERMINAL" in
            "/dev/tty1") setterm -background black -foreground white -store;;
            "/dev/tty2") setterm -background black -foreground white -store;;
            "/dev/tty3") setterm -background black -foreground white -store;;
            "/dev/tty4") setterm -background black -foreground white -store;;
            "/dev/tty5") setterm -background black -foreground white -store;;
            "/dev/tty6") setterm -background black -foreground white -store;;

    You might try adding the following to your /etc/rc.d/rc.local file instead.

    setterm -background black -foreground white -store >/dev/tty1
    setterm -background black -foreground white -store >/dev/tty2
    setterm -background black -foreground white -store >/dev/tty3
    setterm -background black -foreground white -store >/dev/tty4
    setterm -background black -foreground white -store >/dev/tty5
    setterm -background black -foreground white -store >/dev/tty6

    This has the advantage of not having to go through this code every time you login. If you set the background color to anything but black, you might also want to clear the screen as follows.

    clear >/dev/tty1

    Gary Jaffe <>

    And just one more thought...

    This is the cool thing about Linux... there's usually several ways of getting things done and they are all pretty fun to tinker with! Gary's suggestion not only allows you to set each terminal color, but gets things set up without your having to log in first!

    Mucho Cool!

    Also, after playing with setterm a bit more I found that if you include the "-bold" option you can get foreground color enhancement. In other words, I've currently got VT1 set up to be yellow text on a blue background. If you type in simply:

    	setterm -foreground yellow -background blue -store
    the "yellow" is actually rather brown :-( However, to brighten things up a bit, try adding:
    	setterm -foreground yellow -bold -background blue -store
    and things will look a LOT better! :-)

    Give it a whirl!

    Still more VI Tricks by Jens Wessling

    Date: Sat, 14 Oct 1995 10:35:02 CDT
    From: Jens Wessling <>
    To: <>
    Subject: Vi Rules!!


    I just wanted to share some interesting vi tricks with you and see if might be interested in putting them in the gazette.

    The first time I used vi, my reaction was much the same as everyone elses is the first time they encounter it. yechhh!! This makes no sense. Then, over time, I got more and more used to it. I made one brief attempt to use emacs, spent 45 minutes trying to get out, and vowed to return to my old faithful editor, vi.

    The one thing that I have found true of people who use vi, is that the longer anyone uses it, the less objectionable it becomes. It is now more common for me to have random escape sequences in other editors, than it is for me to try to input in command mode in vi.

    First, did you know that vi comes with a configuration file. (like just about every other Linux program) You might think that it would be called .virc. It is not. It is called .exrc. This, for those of you who do not know, is because vi is a full screen derivation of the line editor ex. In fact, in some places, vi and ex are both calls to the same program, which then uses arv[0] to determine whether or not to run it full screen or not.

    Well, what can you do with this .exrc file you ask. Well, I will tell you. First of all, I can't stand the silly 8 character default for tabs. That is way way to large for programming. By the time you have embedded a loop or two, you are shooting off of the screen. To change this to something more reasonable, try adding 'set tabstop=3'. This will take care of setting it for you. You can also use this to set any of the other vi set commands, like beautify, timeout, autoindent, etc. Check them out.

    The next vi trick is a good one. If you have used one of the new Windows based word processors, you may have seen a "new" feature. It is usually billed as a continuous spell checker or something like that. What it does is check what you are typing as you go, and if it recongnizes a misspelling, it corrects it immediately. Well, vi has been doing this for years. And here is how it works. Try adding the following to your .exrc file.

    	ab cant can't
    	ab dont don't
    	ab HW Hello World  

    Now re-enter vi and try typing cant dont and HW. When you type these, they are immediately replaced by what you put on the right side of the ab command.

    This may not seem immediately useful, but it can be extended to do much more. Try adding the following:

    	ab homead sMyNameCtrl+vReturn123 MyStreetCtrl+vReturnMy Twn, MyState

    Now when you type home, it will print out your address. Another handy one that I use is:

    	ab ee

    Now it takes only two key-strokes to put my e-mail address in any document. In case you are worried, it won't replace the ee in 'week' for example.

    This should work on almost all vi editors, but no guarantees. This is just a very small example of what you can do with vi. It is very powerful and easily customizable.

    By the way, there is plenty more where that came from.

    					jEnS Wessling 
    ==== Jens Wessling             == "A compiler ought to compile the    ====  
    ==== ==    comments and ignore the code."   ====
    ====                           ==           M. Minsky(or close to it) ====

    just my 2 cents...

    Jens' letter brought to mind a truism that my Mom used to tell me all the time when I was a kid:

    "There's no arguing about taste."

    I happen to like and use VIM a lot and find, like Jens, that the more I get used to it the more I like it and the faster I can get things done. In reality, the same could probably be said if I'd started to use Emacs first, or Jed, or Joe, or... :-) Since the grist of flamewars is often issues of preference, I appreciate NOT getting flamed for airing my admittedly biased preferences. I'd be ecstatic (or, well... pretty pleased at the very least... :-) if someone who knew something about Emacs wrote in with some ideas or suggestions for using it. I'm still in the process of learning Emacs and can't say that I've had too many epiphanies yet...

    Here's just a couple more little tips to help VI users on their way...

    Using kscreen to clean up that Screen Mess!

    Ok... here's one that really makes my obsessive-compulsive tidy left brain just sing...

    Ever been messing around with something... you know... minding your own business and trying to get a bit of work done when all of a sudden...

    Shaaa ZZzammm!!!

    There's a bit of crackling and popping and suddenly you're looking at a screen full of Sanskrit...?

    Arrggghhh...!!! MEGA-BUMMER! :-(

    I was recently trying to get the recent version of xfig to compile with jpeg support and it stubbornly refused to link in the jpeg stuff after 20 minutes of compiling. Well, in trying to track down the miscretant functions I did a "grep jpeg_destroy_compress * " or something like that, looking for the errant function and suddenly my screen is full of Sanskrit. That's what you get for grepping a bunch of object files...

    No joke.

    OK, well... wanna be like that!... so I just logged out to clear things up and... Hmmm...

    Still lookin' at Sanskrit...


    BUT! Wait! This is Linux, folks, not some cheap imitation OS... (we'll refrain from naming names, eh?) and this one's easy to fix!

    The solution is a simple:

    	echo -ne "\017"

    Cool, eh? :-)

    This handy little item works even on the terminal that's all buggered up. No need to try to kill anything and certainly no need to reboot just to clean up a little mess. You won't be able to see exactly what you're typing which is where the "kscreen" thingy comes in...

    Like a lot of helpful little command line items, this one is ideally suited to make a little fuction out of and stick in your ~/.bash_profile. So, edit your ~/.bash_profile, for all of you BASH users out there, and include:

    	kscreen() { echo -ne "\017" }

    Now, you're all set! Anytime things get buggered up, you just type in the secret incantation "kscreen" (for Kleen SCREEN) and, there you go..., a squeeky klean screen once again!

    Now, just in case you think you're going to forget it... just add the line to the ~/.bash_login or the ~/.bash_profile:

    	echo -ne "\017"
    since these get sourced whenever you login, to clear up your screen, in case you forget the incantation, you just log out and log back in.

    Go ahead... give this thing a whirl... even your Mom will think you're pretty smart :-)

    Changing that xterm titlebar interactively!

    Here's kind of a fun little item...

    You know that there are all kinds of fun things that you can do with xterms... make them big, make them small, change fonts, set colors, execute programs, do console logging... all kinds of fun things that I hope in the future to have time to write up fully. One of those things that you can do is set the xterm title using the "-T" command line option. For instance...

    Suppose you're finally getting tired of seeing the same 'ol blah-looking "xterm" title every time you fire one of these guys up. So... in a fit of daring, you decide that what you really want that thing to say is something like "And what is your wish, Oh Grand One...?".

    You know... something more in keeping with your position in life... :-)

    No sweat!

    You just fire up an xterm using the 'ol command line:

    	xterm -T "What is your wish, Oh Grand One...?" &
    and voila!, instant obeisance! Gotta love this subservience thing... It's YOUR system... rule it! Linux is at your beck and call!

    Welcome to benevolent despotism...

    Hmmm... getting a bit carried away here, eh? :-)

    Anyway, you get the point. You can change the title to anything your heart desires. But suppose that you want to interactively change the title? Or, more to the point, you actually want the titlebar to display some kind of useful information other than just reminding you about what program it is. That is, suppose you want to change the title after the thing is started up or you want to be able to make it display some useful bit of information. Well, let's see what we can do here.

    For those of you who can get your hands on a copy of the "X Window System User's Guide" by O'Reilly, there's a section on Customizing X Window using command line options in Chapter 9. One of the interesting things that is described is using escape sequences to force an xterm to display the current working directory. This is described nicely on page 259. Thing is, you need to be using the C Shell in order to make this work because it uses the "cwd" variable to keep track of where you are. In the process of tinkering around with this I wasn't able to get BASH to cooperate, BUT, I did learn a couple tricks that are kinda fun.

    Without going into a long discussion of what escape sequences are and how they are used, suffice it to say that you can use them to interactively update the xterm titlebar.

    Careful..!! This just might get kinda fun... :-)

    Probably the easiest way to do this is to add an entry to your ~/.bash_profile and include either an fuction or an alias. Let's see how this is done. What you'll need to include is something like the following:

    # use these functions to set the title and label for xterms interactively
    # See the description of this in the "X Window System User's Guide" on p 764
    # The number argument to pass sets the action to take:
    #	0 = change Window/Icon name and Window Title
    #	1 = change Window/Icon name
    #	2 = change Window Title
    # xtitle() let's you set the xterm title interactively.  If you invoke it without
    # any arguments, it defaults to "terminal: xxxx  date: xxxx" format
    	if [ "$*" != "" ]; then
    		echo -n "]2;$*" 
    		echo -n "]2;xterminal:`/usr/bin/tty` date: `date '+%A %B %d, %Y'`"
    # xlabel() let's you set the xterm Window and Icon name
    xlabel() { echo -n "]1;$*" }
    # xtime() prints the current date and time in the xterm titlebar
    	echo -n "]2;current date: `date '+%A %B %d, %Y  %l:%M %p'`" 
    # now, do a similar sort of thing so that we get a more functional xterm
    # title
    if [ "$?PROMPT" ]; then
    	if [ "$TERM" = "xterm" ]; then
    		echo -n "]2;xterminal:`/usr/bin/tty` date: `date '+%A %B %d, %Y'`"
    So, let's see what's going on here.

    The basic idea here is that by sending an escape sequence to xterm, you can cause it to perform certain actions, which in this case is updating the titlebar. The way you do this is by using the echo -n command followed by the escape sequence enclosed in double quotes.

    If you're using the VI editor, the way to enter literal characters (such as an ESCAPE or CTRL-G) is using the CTRL-V, which allows you to enter characters literally or insert the decimal byte value of the character. You'll need this feature in order to enter an escape character and the CTRL-G character. What you'll enter is the following:

    	ESC ] 2 ; text string CTRL-G
    You'll need to enclose all this stuff in double quotes, BTW. So, when you enter this in your ~/.bash_profile, or wherever, you'll type in:
    	echo -n "
    and then hit CTRL-V followed by the ESCAPE key. What this does is insert the literal ESC key into the file, which is represented by the "^[" character. You'll then enter the rest of the stuff until you get to the end where you'll again hit CTRL-V followed by the CTRL-G keystroke. Believe me, this is a LOT easier to do than it is to explain... :-) Tinker with it a bit and you'll see how easy it is. Honest :-)

    So, looking at the examples above, there are a couple variations on this theme. The first, "xtitle" let's you interactively set the title simply by invoking it as:

    	xtitle "What's up, Doc?"
    As you can see, if you invoke this with a character string following it, then it displays this string. If you invoke it without an argument, it defaults to to following line:
    	echo -n "]2;xterminal:`/usr/bin/tty` date: `date '+%A %B %d, %Y'`"
    which outputs something like:
    	xterminal: /dev/ttyp0 date: Saturday November 25, 1995
    on the titlebar. Notice that you're using the "backquotes" or, more correctly, the grave character to enclose the commands for /usr/bin/tty and date.

    This is where mega-coolness steps in!

    See, in this case I've used the tty command to indicate which TTY I'm using. I've also used the date command which, in usual UN*X fashion, has a bazillion command line options that let you do all kinds of fun things. These two commands output the terminal and the date. Kinda functional, but nothing to write home to Mom about, you say...

    But wait! There's a paradigm thingy here!!

    See, using the basic escape sequence feature lets you output all kinds of fun stuff. By using command substitution -- enclosing a command in backquotes which passes the output to the parent command -- you have tremendous control over what can be output.

    Look, for example, at the xtime function. It also uses the basic escape sequence idea but this time, outputs the current time to the title down to the present hour and minutes. Anything that gives you this type of single line output can potentially be used. Time to put on the 'ol thinking hats and be creative! :-)

    Go ahead... get nuts!

    Finally, if you want the titlebar to be customized each time you fire one up, check out the last function listed. What you'll notice is that it consists of an "if" statement that tests whether we're using an xterm (X Terminal) or are at a character terminal. If we're using an xterm, it sends the escape sequence specified. Now, again, there's nothing that says that you can't customize this to be whatever you want... if you really need the affirmation of "Oh, Most Exalted Grand PooBah", then who am I to stop you... :-)


    Oh, BTW, two last little points.

    You'll notice in the comments above the function definitions the mention of changing the window title, the window & icon name, or all three. You do this by changing the argument following the " ESC ] " character pair. The options include:

    	0 = change Window/Icon name and Window Title
    	1 = change Window/Icon name
    	2 = change Window Title
    I've chosen to change the Window Title only, but as you can see you can change the window and icon names as well as the window title using this method.

    And finally...

    If you happen to be using VIM in an xterm you'll notice that when it starts up it sends its own escape sequence (you're not the only kid on the block that knows this trick...) which puts the file name in the titlebar. When you're done editing, it exits which a fond farewell that I'll leave to you to discover. If you want to quiet this habit, simply add the following to your ~/.vimrc file:

    	set notitle
    This prevents a titlebar display and leaves your handiwork unmolested.

    Have fun!

    Space Savings with a Floppy Library

    This one's kind of a nothin' burger little idea that just might be of help to those who are a little cramped for HD space.

    I don't know about the rest of you, but there always seems to be a LOT more stuff that I'd like to install and tinker with than I have the HD space for. Now the 'ol Linux partition is already pushing 600MB and I'm still having to conserve on space to have room for all the great progs out there to play with. I recently started archiving documents to floppy in a space-saving effort and have found that it actually works pretty well!

    If you've got one of those Texas-sized multi-Gig drives and you're just loaded with real estate, you're not going to be very interested in this, but if you're having to keep cramped quarters, this idea might be of some small help.

    The basic idea is simple:

    1. Save ALL the documentation for the programs that you've installed -- either the programs that get installed with the various distributions, or the ones that you've gotten the sources or binaries to and installed yourself.

    2. Gzip these little rascals. By using the "gzip -9" option you can squeeze these guys down to an impressively small size. This is Space Saver Suggestion #1.

    3. Now, move all these compressed documents to floppies. Now granted, floppies aren't cheap and with hard drive costs dropping daily this may or may not be economical for you. I got a bunch of the cheapo no-name 50-count floppies for a little over $20 at one of the local computer head shops.

      What you might want to consider is setting up an A disk, a B disk, a C disk, and so forth... set up a series of disks and save programs alphabetically on these. Start with 26 disks and then add as you need.

      I've formatted my floppies using ext2fs. This is admittedly a bit of inefficiency since ext2 is a good filesystem but it does take up a bit of space all by itself. Still, there's not a great space cost involved and I like to be able to save using long file names and without having to convert text files from UNIX -> DOS. Using ext2 allows this.

      Anyway, you can reformat the disks if you want to use the ext2 or minix filesystem, or whatever you want, and then move files to floppy. Simply create a directory for each program and then move the gzip'ed docs to that directory.

    4. Now, whenever you need to re-read the docs for a particular program you have only to pull the disk, which you've neatly arranged alphabetically, pop it in, and zless the files to view it. This lets you view the file without having to uncompress it.

    The zless program, BTW, is a pretty simple little shell trick:

    for args
        zcat $args | less
    that simply zcat's the files to less. You can now read the docs without having the copy anything to your HD and without having to uncompress anything. This works surprisingly well and is quite fast. For all of you who've set up the supermount program this is especially fast since you have only to pop the disk in to start reading.

    Pretty slick, IIDSSM. (...that's If I Do Say So Myself...)

    Now, I admit that this is kind of "Hints by Heloise"'ish... but if it lets you squeeze one more little program onto your HD, then it's worth it! And maybe next month we'll talk about getting cat pee out of your couch. ;-)

    Anyone have any other space savers...? (I know, I know... besides the " rm -rf /c/windo..." trick...)

    And just one more thought about the topic of archiving stuff...

    It might not be a bad idea to think seriously about archiving the program sources for the apps that you've compiled yourself and installed. The logic for this is pretty simple. Not all programs will let you unfurl the sources and then type in "make" and have a program compile cleanly. Most of the time you have to edit the Makefile or Imakefile, and not infrequently you have to do more than a little tinkering with the sources to get things to compile without complaint. After going to all the work to get things to compile, it's probably not a bad idea to save these changes.

    Again, we're talking pretty simple stuff here:

    1. Once things compile cleanly, get rid of the extraneous stuff -- this is usually simply a matter of doing a "make clean" which get's rid of all the object and temp files and such. Just remember to do this after you've done a "make install" or else you might find your executable mysteriously vanishing...

    2. Next, jot yourself a quick README of your own and include at least the commands you need to get things to compile. Again, this is probably going to be little more than a "make", "make install", "make". But occasinally there's a funky command line option that's needed and it'll save you time otherwise spent re-reading the original README's.

    3. Now, simply tar & gzip the distribution and change the name to something like "program_name-1.34-MINE.tar.gz" which let's you know that you've compiled it and made the needed customizations.

    You may not need to do this at all if you have an adequate means of doing a system backup. If you don't, and you anticipate having to reinstall your system, then being able to quickly recompile and reinstall from sources may be of benefit.

    Anyway, just a thought. ;-)

    Less is just a Whole Lot More!

    Here's a final 2 cent quickie... Sort of FYI

    For those of you who haven't yet discovered this great little program you really need to give less a whirl. For those of you who have, here's a little something that I just discovered recently.

    The other day I was looking through a bunch of usenet news articles trying to find one that I knew I'd saved on 3 button mice. Well, after grepping through the lot of them, I finally came up with several possibilities and decided to have a look at them. Being in a time-expediency kinda mood I tried a:

    	less *.news
    maneuver on those files that I thought might have what I was looking for. This loads up less with a bunch of files to scan. So, what's the trick? Here's a couple things that less will let you do:
    	:n	move to next file
    	:p	move to previous file
    	:v	edit the file using VI
    	h	fire up the online help
    By hitting a colon followed by either an "n" or a "p" you can move to the next or previous file respectively. Want to edit the file? Hit a colon followed by a "v" and suddenly you're in VI, ready to edit. Curious about what other cool stuff you can do with less... just hit a "h" and the online help screen pops up.

    The multiple-file paging capacity is particularly helpful if you're wanting to view several files at once. The editing capacity is also pretty helpful if, as you're reading, you decide to edit the file.

    Nothing to get too excited about but still... Kinda slick.


    Well, congrats... you made it!

    Thanks for hanging in there. I'd like to say a very heart-felt thanks once again to all the folks who've written and offered their sincere encouragement and kind advice, suggestions, ideas, tips & tricks, or just dropped a note to chat about Linux. I've learned a lot from y'all and I appreciate it more than you can know. I especially appreciate the folks who've written from abroad for whom English is not a "mother tongue". English is, admittedly, not the easiest language to learn and I appreciate the effort many of you put out to write.

    That said, I also want to thank again the kind cast of folks that wrote and who's letters and messages ended up in this month's LG. This ain't a one man "dog & pony" show! :-) If you've found something useful here drop these folks a note and let them know it!

    Finally, what's the latest toy around here...?

    Well, now that I've started doing a bit of C++ programming at school, I've really become intrigued by Tcl/Tk programming. For those of you who haven't played with this stuff, it is just too way cool!

    I've been playing with several very cool programs, which really need to be in the 'ol Linux Toybox..., and these include:

    Now, all of these programs can be found, if I recall correctly... :-), on sunsite or one of its mirrors. Forgive me for not giving a URL for these but I just haven't had the time to chase them down this week.

    Also, if any of you are interested in Tcl/Tk, there's a HUGE amount of really great stuff to play with out there. You can't begin to imagine just what's other there until you do a little 'Net crusin' at Yahoo and do a "Tcl" search. It's really worth your while if you're at all interested.

    A couple great web pages devoted to Tcl/Tk stuff include:

    Tcl/Tk Resources
    Tcl/Tk Project At Sun Microsystems Laboratories
    TCL WWW Info

    If you're seriously interested in learning Tcl/Tk programming you'd do well to look for Brent Welch's homepage. He was a Ph.D grad student in John Osterhout's lab and has written an excellent book entitled Practical Programming in Tcl and Tk. There's a postscript file of the book draft available via anonymous ftp for those who might be interested in purusing it.

    Both John Osterhout and Brent Welch have written books on Tcl and Tk programming. I just bought John Osterhout's book with a bit of birthday money and am enjoying reading bits and pieces of it between study/programming/cram sessions (which generally means while I'm in the bathroom... ;-)

    These are definitely items to add to your Christmas wish-list!

    Finally, there's a VERY cool Linux page that y'all should stop by and enjoy:

    The Web Wanderer's List of Linux Applications

    The guys maintaining this page have done something that I was recently thinking of doing... and did it a LOT better than I would have been able. They've assembled a fairly comprehensive list of programs that will run on the Linux platform and provided the URL for the homepages for these programs. These are all categorized by type, so that if you're interested in Graphics, Text Processing, Utilities, or whatever, just drop down to that group and start purusing. A short description of the program is included to give you an idea about what it does.

    Very cool.

    I've been there a few times and have really enjoyed it a LOT. Check it out. Also, if you're a program author, you might want to consider stopping by and giving them your URL.

    Anyway, hope you enjoyed this month's LG! :-)

    See ya next year!

    -- John

    Got any great ideas for improvements! Send your comments, criticisms, suggestions, and ideas.

    Back up to Linux HomeBoy WebPage

    This page written and maintained by:
    John M. Fisk at