Linux Gazette August, 1995Linux Gazette August, 1995
Salutations and the
Mail BagWelcome to the August edition of the Linux Gazette. The Gazette is an attempt to bring together a selection of tips, tricks, and ideas to make running Linux more fun. Pretty shallow..., eh?
Well, this is the 90's. We're supposed to be shallow. Depth isn't on the agenda for another decade or so.
What I'm beginning in this issue and plan to continue through at least the next is to cover some of the things that can be done to make running X Window on your Linux system a bit more fun. Don't believe all the nonsense about X being for gurus or the slightly-deranged. In its "out-of-the-box" configuration it's admittedly a bit of a fix-me-up'er but that's easy enough to change. Besides, you'll want to experiment and tweak slowly and see what actually works and what you like.
Craig Goodrich
<craig@ms.ljl.com> wrote the following:
Just a quick note of appreciation. This and the Keystroke-HOWTO are beyond a doubt the two most valuable frustration-reducers for LinNovices I've seen.
Quick tip for the next issue -- if you have a CDROM on sbpcd, I suggest you patch up to 1.2.9 or .10; the cdrom code is substantially more clever (at least if you have a TEAC, as I do), and go into the sbpcd.h file to get rid of the jukebox effect (opening and closing the thing whenever it's mounted or probed). Then recompile [see issue 1].
Something that's needed is a good review of text editors. I started out in '67 on a keypunch and became a DEC TECO guru in the late '70's, but I've outgrown it -- even the old PE was more usable and intuitive than the outrageously perverse (and bloated) EMACS or the atavistic vi. I glowed with anticipation when I first fired up crisp, being a BRIEF fanatic, but that bubble was soon burst. I unztarred Xemacs (after downloading all 14 meg -- compressed! -- of it through a 14.4 ppp connection -- talk about a load of wash ...) only to have it die with a segmentation fault, since I'm not yet well-ELFed.
Anyhow, I may eventually write up something on all this and submit it to the gazette, if I can just keep my wife convinced that kernel-hacking and playing with Xconfig really is more important than cleaning out the garage or babysitting so she can go shopping.....
Thanks again--
Craig
He also very kindly sent the following URL announcing the upcoming plans by Caldera to work with Novell in porting WordPerfect 6.0 to Linux. Look for it at https://www.caldera.com/WPLinuxRelease.html
Brad Greger wrote:
Just wanted to say thanks for all excellent tips and for the laughs (very humourously written). You have discussed the very things that have been anoying me about Linux and given great solutions; that would have taken Linux newbies (thats me) many hours to figure out on my own.
Please keep the Linux Gazette going!
Thanks, Brad <begreger@artsci.wustl.edu bgreger@thalamus.wustl.edu>
Cimarron Taylor wrote with a
couple suggestions:
Just read your gazette. I fall into the Multiple OS category. I use Linux, Windows NT, Windows and DOS to handle all the different things I do on my laptop. Here are some things I feel no linux installation should be without:
- fips and loadlin
- without these I never would have gotten linux loaded in the first place. I really don't like the concept of replacing the dos or NT boot loader with LILO because there is still so much stuff I need dos and NT for and I don't want to risk losing that data.
- linux netscape
- I bought the windows NT version but I still rely on the linux version to generate good postscript output for printed documents.
- kermit
- perhaps a matter of taste but it works really well with all the sites I dial in to.
- emacs
- wouldn't use linux without it.
The one thing that bothers me most about linux is the problems dealing with data in multiple file systems. Linux can not read or write data in a Windows NT file system and it does not understand extended FAT file names. Similarly Windows NT cannot access data in a linux partition. This means I cannot effectively use all the storage available to me on my laptop.
Anyways, I enjoyed your gazette.
Cimarron Taylor
cimarron@acgeas.com
And Hans Zoebelein <zocki@web.tenn.com> dropped a much appreciated
note of encouragement.
Hi John,
thanks for this refreshing page. Itis one of the best advertisings for LINUX I have seen on the net.
Best regards
Hans
Sorry that I can't include all of your letters. I really did jot a note to everyone that wrote me, although our local mail server yacked up anything farther away than about Boise. So for the folks from Germany and Italy who wrote, my apologies. I'll see if I can get things working.
Anyway, hope you enjoy!
Yup, still more
tar tricks...Ok, so why more tar tricks..?
Well, have you ever taken a look at the man page for " tar " -- it's about a bazillion lines long, and in the world of terse and tight-lipped UN*X that's about as loquacious as it gets. Which brings up one of those interesting character observations about the whole UNIX mystique...
Namely, that it's not very chatty.
I mean, consider MS Windows... Ok, OK! I know you'd all love to flame Billy G. and the Evil Empire to an unrecognizable crisp... but hold your torches for just a second... Ever notice that when you install something there are dialog boxes and messages galore? Stuff like " Hello, I'm your new OS, Windows2005 and I'm about to eat your harddrive alive. " Whereas UN*X barely belches when you innocently type in
su cd / ; rm -rf *
just because your smart aleck roommate told you it'd help clean out some unnecessary files.
But I digress...
Tar really is a pretty impressive beast and is probably one of those quintessential unix-type utilities. The salvation of it is, though, that for most of us to use it requires only a rudimentary knowledge of it. However, on those rainy Saturday afternoons when you've already ironed everything in your closet including the tongues of your tennis shoes... and there's still not much to do, puruse the man page for tar -- there are actually quite a few goodies hidden there.
Let me expound.
The nice thing about tar for all of us " tape-backup-wannabee-havenots " is that it'll let you do multivolume archives. Just add the " M " command line option and you're all set. So, if you wanted to back up your /home/me directory you could use:
cd / tar cvMf /dev/fd0 /home/me
Now, want to maintain absolute pathnames -- i.e., don't strip off leading
" /'s " -- then add a "P".
Want to preserve file permissions -- add a "p".
Want to give it a volume label -- add a "-V "Some cute title " "
Now, this whole thing starts to get a bit out of hand, but it works:
cd / tar -cvpMP -V "Home Directory Backup" -f /dev/fd0 /home/meYou just fire this up, and shovel in the disks. When you're done, you can admire you new handiwork by re-inserting your first disk and then entering:
tar -tvf /dev/fd0You should see your volume label at the top of the archive. If it goes scrolling by at breakneck speed just pipe it through either " more " or " less " or whatever your favorite pager happens to be.
There's one further bit of fun to have here... and then we'll call it quits for today. Honest.
Suppose that you wanted to periodically make a backup of specific files. Now you could hand enter every one of them and then use the "-A" option to append each file to the archive. But that's a lot of work. Instead, you can just have tar read a list of stuff to backup from a file. Use your favorite text editor to create a list of files you want to backup, one file per line, and then issue forth the command:
tar -cvpPM -V "Back me up Scotty..." -T "./backup.list" -f /dev/fd0and you'll discover that you've neatly backed up all those files in your list. Mucho cool.
So, where's this practical? If you're your own sysadmin, and I suspect that many to most of you are, then after a few months you've made some pretty extensive adjustments to your system. One ill-behaved program or one little power surge later and your months of tinkering and tuning may be history. Like Mahamet... it be Ghandi, man.
And since you're still in the "tape-backup-wannabe" group you wisely buy a few disks to back up at least the essentials. One suggestion is to do this by system. For example, if you've been messing around quite a bit with X Window and that baby's humming... Create a list of your config files --
/usr/X11R6/lib/X11/XF86Config /usr/X11R6/lib/X11/xinit/xinit.fvwm /usr/X11R6/lib/X11/app-defaults/XTerm ... /usr/X11R6/lib/X11/fvwm/system.fvwmrc /home/me/.Xresources /home/me/.fvwmsomething like that. Call it whatever you want. Now, instead of having to type in all those names, just tell tar to use your backup.list file to retrieve the names. If you do this by system, then you can create a file for each of the various "systems" you use. By this, I mean X Window, printing, SLIP or PPP configuration, Mail, and so forth. If you make individual backups then you can restore these individually if need be.
Of course, you can always just back everything up en masse and then install individually from that. Your choice.
And here's another 2 cent tip:
Let "find" do some of your dirty work for you. How? Let's say that you wanted to backup all the files in your /usr/lib/ppp directory. You've finally gotten a consistent connection after weeks of tweaking. Man, that connection to the 'Net is your life blood! So, to help save all your hard work try:
find /usr/lib/ppp > backup.ppp.listand there you go. All the file names neatly typed up in your file. If you're a bit of a cleaver chap, you just set up a shell script to do it for you. And here's a word of advice -- if you haven't learned to shell script yet, DO IT!
Shell scripting can make your life a million times easier. No it won't get you a hot date for Friday or clean up after your slovenly self like your mother did... but it makes handling tedious, routine, and retitive tasks much easier. Get a good book on it and learn.
But I've digressed. Back to tar.
Now there are a couple caveats. First, if you're creating multi-volume archives you can't verify the archive using the "-w" option, and maybe as important, you cannot create gzip'ed archives if you happen to be using GNU tar (which is, of course, a far superior product than Brand X tar). Tar simply will not verify or compress a multi-volume archive. Ok, so what? right...
Wrong.
I tried to make a backup of about 5MB of .au sound files recently. So, I used the ol' find trick, made a file listing, muttered the correct incantation, and watched lazily as tar started grinding away on /dev/fd0. It wasn't until it started demanding disks 6 and 7 that I really began to worry. About disk 8 I bagged the fiasco and Ctrl-c'd it. It quietly obliged. Now I'm no rocket scientist at math but it seemed that asking for 8 disks which hold over a MB in order to store away 5MB of files was a bit absurd.
So, now's the time to bring out afio. Afio is one of those great little utilities that really does make life a bit easier. I won't go into all the intricacies about it (we're talking about tar here, right...) but suffice it to say that it easily got my 5MB of sound files onto four disks with room to spare. If you get the archive, take a look at the README files. They'll give you some ideas about how to get things working. Basically, it's:
find . -print | afio ivs 1440k -F /dev/fd0to archive your files in the current directory onto floppies in your first disk drive. Afio actually works best in a formal shell script backup program as it requires a source of file names on stdin. Now you can do the same thing by cat'ing your backup.list to afio. Also, if you add a "Z" to the lineup of options it'll also compress the archive.
The nice thing about using afio with the compression option is that because of the way that afio stores its archives, if one of the files becomes corrupted -- hey, it can happen to anyone -- it doesn't prevent you from retrieving the remainder of the intact files. If you tar and gzip an archive and it has an error, you're out of luck, pal. It's history. The whole thing.
MegaBummer.
By now, we're both getting tired of this so let's stop here. There are apparently some handy pre-made backup scripts available at your favorite local Linux FTP watering hole. I can't say that I've used any yet.
Any product testimonials? Drop me a note.
If you gotta use VI, use
VIM!OK, at the risk of becoming flame-bait, let me quickly put in a blatant plug for a vi clone that I think is actually rather useable. It's the VIM editor and, if you're using a stock Slackware distribution, you probably already have it installed on your machine.
There are three things that I like about the editor:
Because I absolutely HATE getting beeped at incessantly just because I can't tell whether I'm in command, insert, replace, or any other mode. At least with vim you know where you stand.
Second, it has an easily accessible help screen which is called up by entering ":h " when in command mode. This has a bunch of helpful one-liners that are organized by category -- motions, pattern search, inserting text, deleting text, setting editor options, Multi-window commands -- and if you need more information, the distribution comes with a much more long winded reference.doc which is generally found in the /usr/doc/vim directory. Take a look at it.
Finally, vim will easily run in an xterm under X. You even get a rather salubrious farewell once your done -- check out the xterm title when you're done...
Now I realize that there are a LOT of much prettier and user friendly editors for X and believe me, I use them. I think xcoral-2.4 and xwpe are my current favorites. But, it's like anything else... mostly a matter of style and use. If you're having to do a lot of editing, emacs or vi[m] is definitely the way to go.
Why?
Funny you should ask. I really didn't believe this myself until I started learning how to use vi. It really is a lot faster to do things if you can keep your hands on the keyboard and off your mouse. Granted the trade-off is that you've got to learn a bunch of admittedly cryptic keystrokes to use it. But once you've gotten the basics mastered, it's a matter of just adding to your repertoire little by little.
So, what have I found that's handy? Try this...
In command mode enter "v", a highlight block lights up at the cursor position which you can move using standard vi motions -- "j" for down, "k" for up, "h" for left, "l" for right. If you're a touch typer then these are pretty natural. You can also use "G" to take yourself to the end of the file. Once you've highlighted everything, then edit it using standard commands -- "y" to yank, "d" to delete, "c" to change text, and so forth.
There's also a handy tag function that let's you put your "mark" anywhere in a document. For example, suppose you're working on a hypothetical Linux ezine... you know, with a catchy name like the "Linux Gazette", and you're working on it section by section. After finishing one section, you begin the next, and after adding the name anchor, you want to add it to your table of contents.
Well, at the current edit position you go to command mode and hit "m a" which marks this position as tag "a". Now, you go to the top of the page, enter your information, and then hit "'a" which beams you back down to your last edit point.
slick, eh...?
Anyway, there's a lot to learn. Use the online help frequently and using it becomes a LOT easier as you pick up the commands. As I mentioned before, you can also use it very nicely under X. Either fire it up in an xterm, or else if your using one xterm and want to give vim its own then enter:
xterm -e vi [options] filename &this will fire up an xterm. The "-e" option fires up an xterm window which then executes the vi editor. When you're done editing and exit the editor, the xterm ends. Nice and tidy.
Also, if you're needing to cut and paster you can try a couple things. Either fire up vim and use the ":split /home/me/anyfile.doc" option to load up a second file and split the screen, or else, if you're working under X, fire up vim in its own window and cut and paste like you normally would -- typically, this means using button 1 to highlight text, moving the cursor back to your xterm with vim running, and then pressing button 2 to paste it in.
All of the commands to move between a split screen, resizing the screens, moving between buffers and all is outlined in the online help.
Very cool.
A final point. I've been using vi and vim fairly loosely in the above discussion. On my system, I've symlinked vim --> vi (and also, less --> view). You can easily test drive your favorite vi clone by simply symlinking it to whichever clone you like:
ln -sf /usr/bin/elvis /usr/bin/vi OR ln -sf /usr/bin/vim /usr/bin/vi OR ln -sf /usr/bin/nvi /usr/bin/viI've admittedly fallen into a comfortable rut using VIM, I really do think that it's "VI Improved".
Helpful PPP scriptsOk, before we go any further, let me explicitly state three assumptions:
If this is you -- congrats! Getting a stable, and reasonably reliable PPP connection setup can sometimes be a bit frustrating. If you're having trouble there are two very good places to look for help -- the README.linux file that comes with the ppp-2.1.2 distribution (look for it in the /usr/lib/ppp directory); and the Network Administrator's Guide which is part of the Linux Documentation Project. You can find the Network Admin Guide at almost any decent Linux FTP site, generally in the /doc/LDP directory.
Now that you've figured out how to get a connection up and going it's time to make it more convenient and useful. Inititally, my dial up command was a finger numbing:
pppd connect 'chat -v "" ATZ OK ATDT*70,123-1234 CONNECT "" name: myname word: mypassword annex: ppp' crtscts -detach debug modem defaultroute noipdefault /dev/cua1 38400If you've gotten this far -- you're golden. Now, it's time to put Linux to work to make things MUCH easier.
First, start cleaning things up by putting all the pppd options where they belong - in the /etc/ppp/options file. All this is is a plain text file that needs to be readable by everyone using it. It contains single line entries for all of the options you use. For example:
-detach crtscts modem defaultroute noipdefault debugEarly on, I included the debug option just to see what was going on. As the output is automatically converted from plain text to a primitive form of New Guinea tribal ISO-8956.03-glyph using an AI PERL 5.001 script, I quickly deleted that line.
Now, to make the rest of this easier to use I tried my hand at script programming. I'll quickly admit that I'm not much of a programmer, at least not yet. However, the scripts I've set up work for me and they seem to work well. I'm currently using LINUX on a standalone PC with a dial up PPP connection to a local university which offers NNTP news, SMTP mail, and a POP 3 mail server among other things.
Since the university has five dial in lines and does dynamic IP addressing I wrote a couple of simple scripts that do several things:
Since it's easier to show you these than to tell you about them, I've included a name-password-number deleted copy of these scripts. You can probably improve on these, but at least they may give you a start:
So, how else can you make all of this easier? Glad you asked...
If you're running X then try this: you can call up the ppp script program and run it in its own xterm. To do this just type in:
xterm -ls -C -e ppp &Two things are important to note. First, adding the "-C" options displays all of the messages on the xterm that would normally be sent to the console. I use this because I've set up the /etc/syslog.conf file to send error messages and such for PPP to /dev/console so I can see what's going on. Normally, an xterm doesn't print this stuff. If you're running xconsole you'll see it, but I prefer to watch as the connection is established.
Second, adding the "-e" option forces xterm to execute a program -- in this case it's my ppp shell script. Now, want to get fancy? I knew you would...
Why type all of this in when LINUX is more than willing to work for you. There are three simple things that you can do to make this even EASIER:
Create a function, which you can put in /etc/profile or in your own ~/.bash_profile which defines xppp:
xppp() { xterm -ls -g 80x24+360+120 -C -e ppp & }
By setting the geometry, I can make the xterm pop up where I want it. On my screen
this puts it in front of the full screen xterm I use as "home-base".
Now, all I type in is "xppp" and voila, there is my program
running in its own xterm. When the connection is established, I iconify it.
Nice and tidy.
But that's not all that can be done. If you're running fvwm then you can either add it to the pop up menu or set it up as a button in the GoodStuff botton bar.
To add it to a menu item simply edit your system.fvwmrc or ~/.fvwmrc file and include:
Exec "xppp" exec xterm -ls -g 80x24+360+120 -C -e ppp &in any of the popup menus. You could add this to, for example, the Applications menu.
You can also add this to the GoodStuff button bar by adding a stanza such as:
*GoodStuff xppp modem.xpm Exec "xppp" xterm -ls -g 80x24+360+120 -C -e ppp &In this example, I'm using modem.xpm as the pixmap for the button and then starting up the xterm with ppp running in it just as I would at the command line. Now, at startup, just fire up the GoodStuff module and there you are! Press the button and xppp fires up just where you want it.
Too way cool...
Once you've gotten the connection up and running, make the xterm with ppp running an icon and then start the "pppon" program. This will update /etc/hosts, check the mail, start the background programs, floss the cat, and do your wash. LINUX is great.
I'd be interested in any suggestions, criticisms, or comments on these programs. One idea that I haven't gotten around to doing is simply to create an "xppp" program that automatically does all of this and reads the options such as redial time and ping/mail check interval from a ~/.xppprc file. Then, instead of running one program and then invoking the second, it's all included in one program.
Have to think about this one...
Anyway, let me know about your successes, failures, or suggestions!
PINE + popclient - mail for the
sendmail-impairedIf you've got a standalone system - i.e., you're not networked - but have access to an SMTP (Simple Mail Transfer Protocol) mail server that also runs POP(Post Office Protocol) then it is possible to send and receive email without having to set up sendmail.
If the thought of setting up sendmail wads your shorts in a knot and raises your anal sphincter tone...
read on.
It is possible to set up PINE to act as an SMTP client, which will deliver outgoing email to the SMTP server, and popclient which can be used to pick up incoming email from the mail server via POP. The beauty of this type of setup is that it completely obviates (ob.vi.ate [from the Latin obviam]: to see before hand and dispose of: make unnecessary syn see PREVENT) the need to set up sendmail to get mail out of your machine. If your email needs are fairly simple, this is something worth considering. To do this, you'll probably want to do a couple things.
First, you'll want to get a copy of the source for PINE and compile it yourself.
This isn't hard. HONEST.
Trust me.
Get a copy of the latest PINE source -- it should be pine version 3.91 and will be a rather sizeable file weighing in at almost 2MB. You can find a copy of it in the /pub/Linux/system/Mail/readers directory of your favorite sunsite.unc.edu mirror. You can also get it factory-direct. From the "brochure.txt" file in the pine distribution:
Pine, Pico, and UW's IMAP server are copyrighted, but freely available. The latest versions, including source code, can be found on the Internet host "ftp.cac.washington.edu" in the file "pine/pine.tar.Z" (accessible via anonymous FTP).
Once you've retrieved it, you can untar it into your favorite source workplace and get to work on it. The document that gives you ALL the gory details is in the /doc subdirectory and is called "tech-notes.txt". It describes in detail the underpinnings of PINE, outlines its impressive list of capabilities, and then describes what you'll need to do to install it. But fear not, I promised you this would be easy.
The compelling reason you'll want to compile PINE yourself has to do with a simple problem: the "From: " field. You see, most mail user agents like elm, pine, xmail, xmh, mailx, and others are "smart" enough to figure out who you are and where you are. If you've set up a hostname for your machine it will automatically pick that out and add your login name.
For example: I, in a rather cavalier fashion I'll admit, do most of my work under LINUX as root. You know... it's a power thing. Anyway, when I send mail from my machine using any of the aforementioned front ends my FROM: field is automagically filled out and looks like:
From: root@FiskHaus.vanderbilt.eduNow, that wouldn't be too bad except that anyone wanting to REPLY to my message has a bit of a problem:
That address doesn't really exist. My "real" address is transient and is something like dialup0032@ctrvax.Vanderbilt.Edu.
The way to fix that is to recompile PINE. You see, PINE allows you to modify the "From: " field if this is a compile time option. Generally, this is not a desirable quality as it allows nar-do-well's to masquerade as someone else and engage in anti-social activities. However, if you're reading this, you're not likely to fall into that camp.
So, here's a simple checklist of things to do to compile PINE:
[1] untar the archive
[2] edit the file /pine3.91/pine/makefile.lnx if you desire. This file contains
all of the compiler options including stuff like profiling and debugging options.
If you're one of those hair-on-your-chest kinda code hackers... hack away. For
the rest of us, there's really not much that needs to be changed.
[3] edit the file /pine3.91/pine/osdep/os-lnx.h -- this is where the real action
is located. This allows you to define much of PINE's behavior. While most options
can be set via its Setup menu, there are a couple things that can only be set at
compile time, and modifying your From: field is one of these. To do this, you'll
uncomment the stanza that defines this. It will look like:
#define ALLOW_CHANGING_FROMThe nice folks at Washington U. have provided a well commented header file that explains what most of these options are. This is probably the most important for what we're doing here.
build clean build lnxAnd that's it. When all the grinding on your HD has ceased you'll find several nice, shiny new program executables in the /pine3.91/bin/ directory, including pine. You can test drive this right from this directory or copy it to your /usr/local/bin/ directory -- wherever you install new program files.
My configuration appears like:
personal-name = John M. Fisk user-domain = vanderbilt.edu smtp-server = ctrvax.vanderbilt.edu nntp-server = news.vanderbilt.edu inbox-path = /root/mail/mail-in folder-collections =The important entry is the smtp-server variable. If this is filled in with either the IP address or the host name of the SMTP mail server then PINE will act as a SMTP client and simply forward mail to this server.news-collections = default-fcc = postponed-folder = read-message-folder = mail-in signature-file = global-address-book = address-book =
The other important entry is found later on in the configuration menu and looks like:
initial-keystroke-list =I've set the customized-hdrs variable to my correct email address. Now the correct From: entry is included with my outgoing mail and all REPLY's will correctly include my email address. You'll also notice one other thing. In the above configuration file I've also set the nntp-server variable. If this is set you can use PINE as a Usenet news reader. It actually works quite well. If you have access to an NNTP news server you're, like, totally golden!default-composer-hdrs = customized-hdrs = From: John M. Fisk <fiskjm@ctrvax.vanderbilt.edu> saved-msg-name-rule =
Now see, that wasn't so bad!
And setting up popclient is even easier! To do this all you'll need to do is get a copy of popclient from your favorite ftp archive. At the sunsite.unc.edu mirrors its generally kept in the:
/pub/Linux/system/Mail/pop/Put the program file in your favorite /bin directory, somewhere in your PATH, and you're ready to get your mail!
There's one little "feature" of popclient that you must be aware of if you're going to use it. You can set it up to pick up your mail from your server but you had better explicitly tell it where to deposit the mail it picks up. The reason is that popclient, at least the version I'm running, will pick up mail from the server and then try to deliver it to the person with the same login name. This is OK if your POP mail server login name and your local LINUX login name are the same, but if they're not, then popclient can't find anywhere to put the mail and it ends up in the bit bucket. Problem is popclient is such a tidy thing that it also deleted your mail off the server.
Poof! no mail.
Ultra Mega-uncool SuperBummer... no mail.
So, how do you fix it? Easy.
Popclient has a number of command line options including one that will let you specify the file to which mail will be added. On my machine, I invoke it with:
popclient -3 -v -u myname -p mypassword -o /root/mail/mail-in ctrvax.vanderbilt.eduThis invocation configures popclient to (-3) use POP 3 protocol, (-v) use verbose output so I can watch what's going on, (-u) login in with my username, (-p) login with my password, (-o) put the mail into the file /root/mail/mail-in, and finally, pick it up from the mail server ctrvax.vanderbilt.edu.
Do yourself a favor... let LINUX do some work for you. Instead of typing all that mess out every time you want to check your mail, you can set up an alias or a function and then invoke it. Try something like:
popmail() { popclient -3 -v blah.blah.blah... }
which you can add to your ~/.bash_profile file. Then, to invoke popclient with
the correct command line options you simply enter popmail and it
runs the program to pick up your mail.
Before concluding this, though, you probably need to consider the limitations of this type of mail system and determine if you're willing to put up with them:
That isn't much of a hardship.
Where it DOES hurt is when you're running X and want to use one of the more user-friendly mail programs such as xmail, xmh, xelm, or mumail. These have very nice graphical interfaces. They often lack the breadth of features that PINE has, but for simple mail use they are quite handy.
Also, if you have a Web browser running, and if you're running a SLIP or PPP connection you should!, then you won't be able to use the mailto: feature.
All in all, you'll need to weigh out the cost-benefit ratio for yourself. Keep in mind that this setup can be used as an "easy to set up" configuration to quickly get mail in and out while you're hacking away on smail, sendmail, or sendmail+IDA.
Try sendmail+IDA.
Using a combination of the documentation that came with the sendmail+IDA distribution and the Network Administrator's Guide, I was able to get this up and running with less than an afternoon's amount of work. I have very simple email needs and so configuration was fairly simple. All of the various mail clients work well with sendmail+IDA and I'm using the university's DNS nameserver and so can use the sendmail.bind.no executable.
Good luck! If you get things working... congrats! Drop me a note!
Customizing X - So
where is everything...Man, one thing about X...
It's HUGE
Getting X Window running on your LINUX box is one of those unforgetable experiences. For every LINUX Newbie it's the rite of passage. It's the milestone. It's a rush.
Customizing X then becomes a lifelong pass-time. And X will give you more than ample opportunity to do this. Once again, I'm going to make a couple simple assumptions:
Anyway, let's begin...
A few of the more helpful configuration files include:
A Bourne shell script that is responsible for firing up X Window. It looks for the .xinit script in the user's home directory which it will use for instructions as to how to start the client programs. If it finds none it will start an xterm from which a window manager can be started.
A Bourne shell script that, among other things, loads up the resources in various user and system .Xresources and .Xdefaults files, loads up the keymaps in .Xmodmap files, turns the root window a pleasing shade of deep blue (xsetroot -solid SteelBlue), and fires up the fvwm window manager. This is the system-wide X initialization program that can be used with startx.
A Bourne shell script that is found in the user's home directory. If it is present it is used by either xinit or startx to start client programs -- such as xterm, xclock, xman, etc. -- and/or a window manager. This file allows each user to customize her/his X configuration.
A plain text file that sets various X client resources. This particular file can be used with programs like xinit or startx to set system-wide X resources if none are set by the user.
A plain text file in a user's home directory that sets the various X client resources for that user. As with the above file, these resources are loaded using the xrdb (X Resource DataBase) program.
A plain text file feared and hated by all X Newbies and the cause of untold misery, anorexia, irritability, PMS, premature balding, and the federal deficit. It's also used by the X server to set necessary configuration parameters.
A Bourne shell script that, in its own words:
# This is just a sample implementation of a slightly less primitive # interface than xinit. It looks for user .xinitrc and .xserverrc # files, then system xinitrc and xserverrc files, else lets xinit choose # its default. The system xinitrc should probably do things like check # for .Xresources files and merge them in, startup up a window manager, # and pop a clock and serveral [sic] xterms. # # Site administrators are STRONGLY urged to write nicer versions.
A plain text file that is used by xmodmap to set key mapping under X. The xmodmap program, in its own words:
The xmodmap program is used to edit and display the key- board modifier map and keymap table that are used by client applications to convert event keycodes into keysyms. It is usually run from the user's session startup script to configure the keyboard according to per- sonal tastes.
In plain english, this allows you to remap your keyboard if you're so inclined.
A plain text file that is used by the fvwm window manager to set up a myriad (myr.i.ad [from the Greek myriad-, myrias]: an immense number :ten thousand, INNUMERABLE) of configuration options. Truly a joy to hack.
ibid., but in the user's directory.
The directory in the LINUX FSSTND that houses the X client app-defaults that set the default resources for these programs.
I'm sure that I've forgotten something, but these are some of the more important files and directories that are used to configure X and its clients.
So, where do you go from here? There are probably two things that you'll want to do. First, MAKE BACKUP's OF EVERYTHING!! Make a backup of all those configuration files that came with the distribution.
Why?
If you break it, you can fix it. Without a backup, you can be seriously hosed. There's nothing like pawing through a pile a 40 disks looking for the set that has the series that has the archive that has the file that has the default configuration to fix something that you, in a moment of blinding stupidity, mucked with and now can't remember what you did. It's like the old " flea on the spot on the frog on the bump on the log in the hole in the bottom of the sea " problem. You get the picture.
Back up. You'll never regret it.
Second, buy a scratch pad notebook and use it for all your tinkering around with the system. Some of the best tweaking and tinkering is aided by pen and paper. Honest.
Anyway, enough of that. Let's DO something.
Customizing X with
vgasetThere's a nifty little utility that truly represents one of those must-have utilities: vgaset. What's it do? It's used to help tune your X Window geometry. Basically, once you've found a modeline entry that works, no matter that it's a bit lopsided and skewed to the left, vgaset can interactively help you tune it up so you can stop constantly having to use your monitor controls to size and place the window. If your monitor doesn't have these controls then it's even more important to know how to use it.
So, OK. What'll you need to know? Vgaset needs information from the modeline entry that you are currently using. That is, it needs to know:
Section "Monitor"
Identifier "RandomMonitor-0"
VendorName "Unknown"
ModelName "Unknown"
BandWidth 70
HorizSync 31.5 - 48.5
VertRefresh 50 - 100
Modeline "800x600" 49.87 792 808 928 1032 768 768 772 785 +hsync
Modeline "1024x768" 64.98 1024 1032 1176 1344 768 768 774 785 -hsync
Modeline "640x480" 31.50 712 752 798 896 503 511 514 544
EndSection
From my monitor's manual I know that my min and max horizontal freq's are
31.5 - 48.5 KHz and that my min and max vertical freq's are 50 - 100 Hz.
I'm currently using a virtual desktop of 1152x900 and am using the
"800x600" modeline entry which has a dot clock frequency of 49.87.
Thus, to use vgaset, I fire up an xterm and invoke it using:
vgaset -d49.87 -x31.5 -X48.5 -y50 -Y100 -v 1152 900CAVEAT: Since messing with monitor settings indescriminately can fry your monitor, READ THE MANPAGE FOR VGASET BEFORE YOU USE IT.
Don't say I didn't warn you. Still, if you follow the directions, vgaset can be a huge help. Once you get it running, you can interactively change the modeline settings which can change the size and orientation of the X Window display.
There are single letter commands that allow you to change the settings:
Commands:
l - decrease the left margin
L - increase the left margin
r - decrease the right margin
R - increase the right margin
h - decrease the horizontal sync pulse width
H - increase the horizontal sync pulse width
t - decrease the top margin
T - increase the top margin
b - decrease the bottom margin
B - increase the bottom margin
v - decrease the vertical sync pulse
V - increase the vertical sync pulse
x - decrease x-resolution
X - increase x-resolution
y - decrease y-resolution
Y - increase y-resolution
? - reset initial values
CR - redisplay the settings.
q - quit
EOT - quit
So, if your root window is too wide/narrow try using the x or X command to
change the horizontal size. Likewise, use the y or Y command to change the
vertical size. Use the L, R, l, and r commands to position the margins so that
the window is centered.
Once you've sized and positioned the window where you want, jot down the modeline values. On my machine it looked like:
Horizontal frequency: 48.3 kHz, vertical frequency: 58.3 Hz Horizontal sync 2.41 us, vertical sync 82.78 us Horizontal retrace 4.81 us, vertical retrace 786.36 us Top margin increase 50 792 808 928 1032 791 791 795 830There's a LOT of information provided here but what you're primarily interested in is that last line. Use it to create an entry such as:
modeline "800x600" 49.87 792 808 928 1032 791 791 795 830in your XF86Config file under the "Monitor" section. If you then list this mode as the first entry in your "Display" subsection Modes list then it will be the first mode that X will use.
Cool, eh?
Ok, so all we've done so far is move the window around a bit. BIG DEAL...huh? Well, let's really spiff up X...!
Customizing X with the
Xaw3d libs!Of all the customizations that can be done for the stock XFree86 distribution, the one that is the EASIEST and possibly the most immediately impressive is installing the libXaw3d libs. But I'm sure that all of you have already done this because in the July, 1995 (Issue 15) edition of the Linux Journal there was an excellent article by Mark Komarinski on page 54 entitled "Installing the Xaw3d Libraries". I'm sure there's no need to...
Pardon?
What!! You don't get the LINUX JOURNAL!!
Don't be a cheapskate! Repent thou niggardly skinflint!! These guys at Specialized Systems Consultants, Inc (SSC) are doing a great job of putting out an excellent resource for the LINUX community.
Seriously, you really do need to get this magazine. You get a year's subscription for a $22 and more importantly, you provide the support for all the hard working folks at SSC responsible for its production. The July edition had articles such as:
Linux Journal P.O. Box 85867 Seattle, WA 98145-1867
I really am impressed with work these guys are doing and they deserve your support. You, on the other hand, deserve the fruits of their hard work. These articles really are quite helpful and give you a larger picture of what's happening in the LINUX community.
Back to the topic.
Setting up the Xaw3D libs is such a breeze that it'll make you feel good about yourself once again. Honest. So just exactly what are these things? The Xaw3D libs are the shared libraries of X Window Athena Widgets. Widgets are the building blocks, if you will, of the graphical components of the X clients. Widgets are the menus, buttons, boxes, sidebars, title bars, and so forth that are put together to create the graphical component of a program. The original Athena widgets, from the nice guru's at MIT, are referred to as Xaw. These new 3d widgets were designed to give X a Motif-like 3D appearance.
The beauty of it is, that the new libXaw3D library is simply a drop-in replacement for the old libXaw library. Installation is a cinch. Trust me.
So what do you need to do? Here it is:
tar -tvf Xaw3D_X11R6.tar.gz or whatever
the name of the file is -- to make sure that it's not stored with absolute
paths. If it is, you'll probably want to untar it from your root (/) directory
so that things are put where they belong. These libraries generally end up in
your /usr/X11R6/lib directory. If there are simply a series of files, you can
safely untar them anywhere and then copy or move them to your /usr/X11R6/lib
directory. BUT NOT BEFORE YOU...
cp libXaw3d.so.6.0 libXaw.so.6.0.
ldconfig at the command line. This program automatically updates
the links between the actual library files and the file that ld.so will
be looking for. You see, for programs that are dynamically linked to the
libXaw library, ld.so will be looking for a file called libXaw.so.6, NOT
libXaw.so.6.0. So, the program ldconfig creates the proper symlinks so that
ld.so can find these files.
Gotten this far? You're almost done!
The final bit of housekeeping is to add the necessary resources to make the Xaw3D widgets look nice. This is also very straight-forward. Simply add the following bit of configuration to your personal or system-wide .Xresources file:
! Good Xaw3d Defaults ! *Form.background: #c0c0c0 *TransientShell*Dialog.background: #c0c0c0 *Command.background: #c0c0c0 *Menubutton.background: #c0c0c0 *ScrollbarBackground: #c0c0c0 *Scrollbar*background: #c0c0c0 *Scrollbar*width: 15 *Scrollbar*height: 15 *Scrollbar*shadowWidth: 2 *Scrollbar*cursorName: top_left_arrow *Scrollbar*pushThumb: false *shapeStyle: Rectangle *beNiceToColormap: False *shadowWidth: 2 *SmeBSB*shadowWidth: 2 *highlightThickness: 0 *topShadowContrast: 20 *bottomShadowContrast: 55
Alternatively, you can try these that were included with the Linux Journal article:
*background: LightSkyBlue *Form.background: grey90 *TransientShell*Dialog.background: bisque3 *Command.background: gray80 *Menubutton.background: gray80 *ScrollbarBackground: gray70 *Scrollbar*width: 16 *Scrollbar*height: 16 *Scrollbar*shadowWidth: 2 *Scrollbar*cursorName: top_left_arrow ! You can change the above to all kinds of icons, including gumby. ! Find out what icons are available by looking in ! /usr/include/X11/cursorfont.h - be sure to strip off the XC_ *Scrollbar*pushThumb: false *ShapeStyle: rectangle *beNiceToColormap: false *shadow*Width: 2 ! The above defines all shadowwidths to 2. *Label*shadowWidth: 2 ! The above overrides the definition from a few lines above for Label ! widgets. *SmeBSB*shadowWidth: 2 *highlightThickness: 0 *topShadowContrast: 20 *bottomShadowContrast: 40 ! The above two lines define how the shadows appear on the top and ! bottom of teh widgets. The higher the number, the lighter it is. This ! particular setting makes the top and left sides darker than the ! bottom and right sides.
You're now ready for a test drive. Make sure that the above has been added to your .Xresources or .Xdefaults -- whichever is loaded by xrdb at initialization -- and then fire up X. If you set your xterms up to include sidebars then you should see an immediate difference. Try firing up something else. Try xedit or something that uses the libXaw widgets and you'll notice a distinctive improvement.
Congrats! X has just had a major facelift.
So... what's in store
for the next edition of the Linux Gazette?Well, as always, there's a LOT more to write about, but this has already grown a bit out of hand. I've been messing around with X for some time now and there's so much that can be done to make it a lot easier, prettier, and more fun to use. And the basic skills are pretty easy to get a handle on.
My sincerest thanks to all of you who've written. I mean it.
So, what's in store? Well, I've got pages of drafts and ideas jotted down that were all supposed to fit in this edition. Soooo... next month's edition will be a WHOLE LOTA X, including:
Hope you've enjoyed!
I've talked with the gracious hosts of the Linux Gazette at Tennessee CommerceNet who have tentatively given an OK to set up a bit of ftp'ing. I'd be willing to put monthly editions of the Linux Gazette, including the html code and images, into a tar.gz file for downloading. This might make purusing it at your leisure a bit more leisurely. I'm also willing to make available a plain text version as well.
If there's any interest in this, better let me know. Otherwise, I'll just keep putting these online.
And if ANYONE broaches the subject of a PostScript file...
No.
Get real. Get a life. Or at least get a decent browser. :-)
Y'all come back now...
Back up to Linux
HomeBoy WebPage