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 command.com, 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:
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:
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.
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!!
). 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]
Date: Mon, 16 Oct 1995 08:09:06 CDT
From: System Administrator <[email protected]>
To: <[email protected]>
Subject: Linux Gazette
Here's a little something I whipped up. Thought you might be interested...
CUT-HERE-----------------------------------------------------------------------
#!/bin/bash
#
# Ross J. Micheals (1995)
# [email protected]
#
# 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.
#
###########################################################################
# CUSTOMIZEABLE SECTION #
###########################################################################
#
# Location where you want to put the copies of the distribution files
#
DIR_DIST='/root/config_dist'
#
# Location where you want symbolic links to all of the configuration
# files that you have changed
#
DIR_LINKS='/root/links'
#
# Default editor
#
EDITOR='emacs'
#
###########################################################################
#
# Current directory
#
CURR_DIR=`pwd`
# Make sure user is logged in as root
if [ "$LOGNAME" != "root" ]
then
echo "hack: user not logged in as root"
exit 1
fi
# Make sure the user typed in a filename to *hack*
if [ "$1" = "" ]
then
echo "hack: filename is missing"
exit 2
fi
# Make sure the filename to *hack* is a real file
if [ ! -f "$1" ]
then
echo "hack: filename is bad or is a directory"
exit 3
fi
BASENAME=`basename $1`
# Create $DIR_DIST and $DIR_LINKS if it does not exist already
if [ ! -d $DIR_DIST ]
then
echo "hack:" $DIR_DIST "not found"
echo "hack: creating" $DIR_DIST
mkdir $DIR_DIST
chmod 711 $DIR_DIST
fi
if [ ! -d $DIR_LINKS ]
then
echo "hack:" $DIR_LINKS "not found"
echo "hack: creating" $DIR_LINKS
mkdir $DIR_LINKS
chmod 711 $DIR_LINKS
fi
# Create the backup file (finally!)
if [ ! -f "$DIR_DIST/$BASENAME.dist" ]
then
cp $1 $DIR_DIST/$BASENAME.dist
echo "hack: creating file" $DIR_DIST/$BASENAME".dist"
elif [ -f $DIR_DIST/$BASENAME.dist ]
then
echo "hack:" $DIR_DIST/$BASENAME".dist already exists"
else
echo "hack: fatal error in destination file"
exit 4
fi
#
# Create the symlink
#
if [ -f $CURR_DIR/$1 ]
then
if [ $CURR_DIR = "/" ]
then
ln -s "$1" "$DIR_LINKS/$BASENAME"
echo "hack: linking" $1
elif [ ! -L $DIR_LINKS/$1 ]
then
ln -s "$CURR_DIR/$1" "$DIR_LINKS/$1"
echo "hack: (c) linking" $CURR_DIR"/"$1
fi
elif [ -f $1 ]
then
if [ ! -L $DIR_LINKS/$BASENAME ]
then
ln -s "$1" "$DIR_LINKS/$BASENAME"
echo "hack: linking" $1
fi
else
echo "hack: something is fundametally wrong here"
fi
$EDITOR $1
exit
CUT-HERE-----------------------------------------------------------------------
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
<[email protected]>
[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:
- Ross J. Michaels
- Judith Elaine
- Nick LeRoy
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:
NEVER HACK WHAT YOU CAN'T UNHACK!
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]
Date: Mon, 16 Oct 1995 19:47:49 CDT
From: Judith Elaine <[email protected]>
To: <[email protected]>
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 ------------------------------
#!/bin/sh
#
# /usr/local/bin/savemod -- in the spirit of safehack
#
# Copyright (c) 1995 Judith Elaine
#
#
DIR=/usr/local/modifications
\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.
Hmmmm.
Just about halfway through the 8 Meg....
Thanks again for an EXCELLENT resource!
Cheers,
Judith Elaine
<[email protected]>
[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]
Date: Tue, 07 Nov 1995 14:42:15 CST
From: Nicholas R LeRoy <[email protected]>
To: <[email protected]>
Subject: Linux Gazette
John..
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 sendmail.cf 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'.
- Obtain and install.
Probably should do: man rcsintro for an introduction
- 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).
- To Check out a file:
co -l file Checks out the file (now writable).
You may now modify the file.
- 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).
- To get a log of the file:
rlog file
- 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
<[email protected]>
+--------------------------------------+-------------------------------------+
| /`-_ Nicholas R LeRoy | Linux -- What *nix was meant to be. |
|{ }/ [email protected] | 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]
Date: Sat, 04 Nov 1995 23:54:50 CST
From: Daniel Sully <[email protected]>
To: <[email protected]>
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:
sunsite.unc.edu:/pub/Linux/kernel/patches/diskdrives/supermount-0.4a.tar.gz
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
[email protected]
.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 <[email protected]>
To: John M. Fisk <[email protected]>
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.
Daniel
[email protected]
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 sunsite.unc.edu 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:
- unarchive the file and read the README's
- apply the kernel patch
- edit /etc/fstab
- reboot the system
When you unarchive the file you'll find the files:
supermount-0.4a-1.2.13.ud.gz
supermount-0.4a-1.3.30.ud.gz
supermount-README
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
-OR-
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:
mount
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]
Date: Sun, 22 Oct 1995 01:31:27 CDT
From: <[email protected]>
To: John M. Fisk <[email protected]>
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:
- c7 is the VT (use c1 for VT1, c2 for VT2, etc...)
- 45 are the runlevels, use this for a default Slackware,
use 3 for a default RedHat.
- respawn makes it come back if the process dies for
some reason...
- /usr/bin/tail is the command to run, in this case
tail -f, which displays the tail end of a
file and continuously displays new stuff
as it is appened to the file.
- /var/adm/log.smb is the filename to display on
the VT.
- /dev/tty7 is the VT to display to, should match the
first field.
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 >>>-=-=-=-=-=-=-=-=-=-=-\
| [email protected] -- 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...!
--John
Date: Sun, 05 Nov 1995 21:05:00 CST
Sender: <[email protected]>
From: Gary Jaffe <[email protected]>
To: <[email protected]>
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;;
esac
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 <[email protected]>
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!
Date: Sat, 14 Oct 1995 10:35:02 CDT
From: Jens Wessling <[email protected]>
To: <[email protected]>
Subject: Vi Rules!!
Hi,
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 [email protected]
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 ====
==== [email protected] == 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...
- You know that using the "/" forward slash lets you
grep through your file, but using the "?" question
mark (in command mode) lets you perform a backwards search.
Also, hitting the letter "n" will repeat your search
in whichever direction you were last going.
So, for example, if you were looking for each occurance of a
URL beginning with "sunsite.unc.edu" you'd simply
enter:
/sunsite.unc.edu
while in command mode and the search would take you to the next
instance of this entry. Hitting "n" lets you repeat this
forward search. Now, hitting "?" will let you do a
backwards search. Hit "n" now and it'll continue to do
a backward search.
- Want to repeat a prior command but are too lazy to type it all in? :-)
Hey, that's cool... we can do this... Just hit the "."
period while in command mode and Shaaa Zzzamm!! instant
"your-wish-is-my-command" type dito service!
- Hey, ever typed something up, gone to print it, and realized that your
margins were just a bit too long and your sentences were
getted decapitated at the ends...?
Bummer! ;-)
Well, you could go back and try to hack around with moving things
around, OR you could let the nifty little program fmt do
a bit of formatting for you. This handy dandy little app will
format the stuff piped into it into neat little 72 column
paragraphs. It doesn't justify the text, but it DOES keep your
right hand margins at about 72 so everything gets printed nicely.
Since I'm using VIM, I can highlight the text I want to format using
the "v" option while in command mode. Moving the cursor
highlights the text I want to pass to fmt. Now, just hit the
"!" exclamation point key and type in "fmt"
after the exclamation point.
Hit ENTER and, PRESTO!, instant neatness.
Very cool.
Now, you can do the same thing from the command line: Just
type in the row numbers that you want to process followed by
the exclamation point. So, if you want to format lines 10
through 50, you'd type in:
:10,50! fmt
hit the ENTER key, and it's done!
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...
Bummer.
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 :-)
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
#
xtitle()
{
if [ "$*" != "" ]; then
echo -n "]2;$*"
else
echo -n "]2;xterminal:`/usr/bin/tty` date: `date '+%A %B %d, %Y'`"
fi
}
#
# 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
#
xtime()
{
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'`"
fi
fi
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:
else
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... :-)
Enjoy!
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!
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:
- 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.
- 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.
- 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.
- 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:
#!/bin/sh
for args
do
zcat $args | less
done
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:
- 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...
- 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 install.man". 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.
- 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. ;-)
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:
- ical which is a very cool, and very useful personal
calendar/todo/appointment manager. I've used the XVIEW
program xcalendar for a while and it is pretty minimalistic,
although adequate for simple needs. I've also tried the
absolutely fantastic program plan-1.4.x which is a
real powerhouse program. Any of you that have used this
will know what I mean. It's a great program.
Still, I've found that I gravitate to the programs that have
just the right mix of features -- the things that I really use.
Plan was a bit of overkill for the simple things that I need
on a day to day basis, while xcalendar was a bit too spartan.
Ical has been a true pleasure and I've started using
it a lot. I'll leave it to you to be the judge.
- addressbook is another very cool Tcl/Tk program that is
also "just right". As the name implies it is an
addressbook with a lot of very nice extras. I've just
started playing around with this one and haven't even had
time to enter all the "friends -n- family" numbers
yet...
Still, it looks to be a great little program which should be
a lot of fun. I'm thinking of creating a GoodStuff button
bar with several of these "desktop apps" which can
be called up easily. There are several of these little
programs such as ical, addressbook, xpostit, and plan
that really help with day to day organization. I'll let you
know how things work out.
- xskim which is part of the skim package. For those
of you that have standalone systems and get you mail and news
over a PPP or SLIP link, you really should give this little
program a whirl.
I've used a few of the news readers including xrn, tin,
PINE (which has a newsreader feature), & rn. These
all work fairly well but are VERY slow with the NNTP server
I use at school. In a fit of frustration, I finally started
looking around for a better, or at least faster, newsreader
and came across skim.
This great little program allows you to do all of your usenet
newsgroup reading offline, which is VERY convenient. After
the basic setup, which is well documented and is quite easy,
you simply create a list of newsgroups that you want to
subscribe to and when you invoke it, it'll first get all of
the subject headers for the groups you're intersted in. You
then pick the articles you think look interesting and it'll
then go back and pick up only those articles and then save
them to disk.
Thus, you pick up only the articles you're intersted in AND
you can read them offline.
Mucho too way cool! :-)
I use the xskim X interface, a Tcl/Tk app, for all
of this. It is admittedly a bit less than "full
featured" but it works quite well and has been very
reliable. I've now able to keep up with several of the
comp.os.linux.xxxxx groups which is GREAT!
The other very nice thing about xskim is that because
it's written in Tcl/Tk it is eminently hackable. I've been
tinkering around with it a bit and have had a lot of fun
learning about Tcl/Tk from it.
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
Back up to Linux HomeBoy WebPage
This page written and maintained by:
John M. Fisk at
[email protected]
Linux Gazette November, 1995
News Flash!
This One's for You!
Welcome to the November edition of
the Linux Gazette !
Salutations and the
MailBag 
PPP script follow up by Adam
Schlesinger: