From: Adam S. Moskowitz
Subject: Back Bay LISA info. in your magazine
Date: Mon, 30 Nov 92 11:3E1:37 EST
To Sys Admin:
It seems that information about the Back Bay LISA organization
in a recent issue of your magazine. While we appreciate
we need to ask that you inform your readers of this
Back Bay LISA exists only as an electronic mailing list.
We do not
publish a newsletter, nor do we distribute information
in any form
other than electronic mail. Please do not call us asking
to be added
to the list; list membership is by electronic request
only. Send requests
Adam S. Moskowitz
(The keepers of email@example.com)
I just read your Nov/Dec magazine and thought it was
great. I am a
new user of UNIX (Interactive) and found the articles
I thought I'd make a few suggestions on future articles:
-how to connect modems to your system - either to PC
COM ports or
multiport serial boards.
-UNIX based BBS systems
Can't wait 'til your next issue.
Thanks for the kind words. A series on UUCP by Chris
beginning in this issue ("UUCP -- The User's Perspective,"
p. 64) may be helpful. Also you might get a copy of
or the UUCP book out of the O'Reilly series. I think
they will help
you get oriented. --rlw
I'm writing to applaud David Knight's article on Coherent.
have referred to the v3.0 and v3.1 releases as "toy
"training aid," etc. I have been playing around
product for some time and feel that it has a bright
with most other UNIX-derived operating sytems being
as pointed out in Bruce Hunter's article.
Knight's article covered nearly everything, but I'd
like to add my
own two cents worth. Much of the COHware stuff was folded
systems -- beginning with v3.1 -- so it's a growing,
hacker-supported thing. That alone is insurance for
longevity in some
areas. But COFF binary compatibility has made it a real
much existing "shrink-wrap" software can be
used. I know several
people who have tried the vertical applications [which
gave them trouble
on other systems] with success that amazed them. One
-- expecting nothing, really -- and now is considering
Coherent with his business based on that program.
David's compiler tests are commendable and I love his
Boot Disk" script, but wonder why he didn't have
a 5.25" floppy
selection built in, since the target audience is much
to use them. The Adaptec SCSI support is mature (worked
well in the
286 version) and I have good reason to know. IDE drives
were a problem
earlier on and MWC's support people offered little help.
to hand me off to Seagate tech support, who knew absolutely
about the problem. I got disgusted and so installed
a SCSI, which
worked like a champ. The problem apparently wasn't with
with their installation program, which was a bit flakey
- still is,
for that matter. They oughta use a script like other
David neglected to mention that while MWC doesn't support
line editing, they DO provide MicroEmacs for that purpose.
may object to that, but they're probably the same ones
XWindow support. Can't understand some folks! As with
Minix, you get
plenty of editors to select from here. While many things
work a bit
differently with options, etc., UNIX people are used
to that and most
everything does work well.
The small load on system resources is surprising to
many people. They
have squeezed a whole lot into a very small space here
and I am as
impressed by that as the price -- about 1/10th the competition's
equivalent packages. I don't know what kind of numbers
has sold, but it obviously is taking off compared to
the old, early
80's version. I hope that you will be covering Coherent
I'm quite happy with Sys Admin, and articles such as
this are the
The main feature which I've been waiting for in Coherent
virtual consoles. They are vital to the small system
user. I can't
get along without them, myself. Now, if they can just
work out that
355 St. Emanuel St.
Mobile, AL 36603
Thanks for the information about Coherent's disk support.
I agree that virtual consoles and competent COFF support
important. It'll be interesting to see what effect Coherent
the UNIX market. --rlw
From: Kenneth Porter
Subject: In-Line Input or Bust, SysAdmin 1:4
After scanning over your article, I'm puzzled. It seems
that the major
point was to develop a way to construct a temporary
file name for
a script. Was there some reason that you avoided the
syntax? In most shells, "$$" evaluates to
the value of the
process number, and can thus be used to qualify a file
name to make
it process-specific. Thus, instead of using
you would use
It's also common in Bourne shell scripts to use the
command to delete the temporary file in the event of
trap "rm -f /tmp/$$.sql ;
exit" 0 1 2 13 15
This has the effect of deleting the temporary file upon
receipt of any of the specified signals (normal exit,
One additional comment: Finding a temporary name by
looking for a
file name that doesn't exist is somewhat dangerous if
could be using the same routine to make such a name.
By encoding the
process number into the file name, the possibility of
considerably reduced. It would therefore be a good idea
to use $$
as part of the argument to your tmpname program. If
more than one
machine could be using the same directory for temporary
should also encode the hostname or network address into
the file name.
Note that using the pid of the tmpname program is not
as two programs running a short time apart could end
up with the same
pid. The pid of the script should be used.
Kensington Labs Inc.
Leor replies: Probably the "main" reason
I had forgotten about $$'s existence. However, I began
using my own
"tmpname" program primarily because I like
the C library function
tmpnam()'s feature of letting you specify the first
of the filename. That way, if a file does get left lying
/tmp, you can easily identify the application script
probably fix it by adding a trap command such as in
Also, if you need several temp files in the same script,
each successive call to my tmpname program gives you
a unique filename.
Sure, you can manage all these features by hand when
construct the filename using $$; in all but the most
(such as when there may be a variable number of temp
this would be no more complicated than using tmpname.
If I had been
conscious of $$'s existence, I would probably have used
it in many
As for using trap commands to clean up temp files after
an abnormal termination, I try to do that in all (most
of?) my scripts.
Thank you for the feedback!
From: Art Botterell
Subject: What Jim Said
I want to let you know how pleased I am with the direction
taking Sys Admin.
I'd also like to second Jim Wojno's suggestion (in his
in the Nov./Dec. '92 issue) of an article -- or maybe
even a series
-- on porting software.
Specifically, I'd be very interested in learning about
and pitfalls of installing some of the common free software
(PERL, Kermit, etc.) on various platforms.
I think that might be useful for a number of us who're
having to learn
system administration from the top down instead of from
California Office of Emergency Services
Well, we'll try, but porting raises some interesting
questions. For example, I recently recompiled MicroEmacs
(from the C Users Group Library) to run a Xenix machine.
is carefully written to compile in several environments,
VAX, Amiga, Xenix, and UNIX. Unfortunately, changing
#defines wasn't enough; there were four lines missing
from a critical
data structure. Apparently, the author hadn't been able
to test his
UNIX version on a UNIX host.
The question is: where does porting end and debugging
I don't think C debugging techniques belong in Sys Admin,
nor C syntax,
nor general programming techniques. I do think that
syntax and debugging
for certain special purpose languages, like shell script,
awk, are appropriate. We'll try to find a happy balance
By the way, if you are trying to install MicroEmacs,
are several fields missing from the term data structure
unix.c. Compare it to the structure defined tcap.c to
find the missing
Subject: "Building Internet Firewalls"
In the July/August issue, Russ Hill asked for, among
articles about configuring routers. There was an article
Internet Firewalls" in the February 1992 issue
of UnixWorld that
addressed this issue.
I found it quite informative.
Product Specialist MHS
Comma Data Service AS
Thanks for the pointer. -- rlw