New Messages
From: Adam S. Moskowitz It seems that information about the Back Bay LISA organization appeared in a recent issue of your magazine. While we appreciate the publicity, we need to ask that you inform your readers of this important fact: 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 to "bblisa-request@inset.com".
Thanx,
Dear Editor, 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 Hare beginning in this issue ("UUCP -- The User's Perspective," p. 64) may be helpful. Also you might get a copy of UNIX Communications, or the UUCP book out of the O'Reilly series. I think they will help you get oriented. --rlw
Dear Robert, Knight's article covered nearly everything, but I'd like to add my own two cents worth. Much of the COHware stuff was folded into the systems -- beginning with v3.1 -- so it's a growing, living, hacker-supported thing. That alone is insurance for longevity in some areas. But COFF binary compatibility has made it a real bargain because 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 tried FilePro -- expecting nothing, really -- and now is considering using Coherent with his business based on that program. David's compiler tests are commendable and I love his "Emergency Boot Disk" script, but wonder why he didn't have a 5.25" floppy selection built in, since the target audience is much more likely 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. They tried to hand me off to Seagate tech support, who knew absolutely nothing about the problem. I got disgusted and so installed a SCSI, which worked like a champ. The problem apparently wasn't with drivers; but with their installation program, which was a bit flakey - still is, for that matter. They oughta use a script like other folks. David neglected to mention that while MWC doesn't support vi command line editing, they DO provide MicroEmacs for that purpose. Some purists may object to that, but they're probably the same ones crying for 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 Mark Williams has sold, but it obviously is taking off compared to the old, early 80's version. I hope that you will be covering Coherent regularly. I'm quite happy with Sys Admin, and articles such as this are the reason why. The main feature which I've been waiting for in Coherent is those 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 networking...
Yours truly, Thanks for the information about Coherent's disk support. I agree that virtual consoles and competent COFF support are important. It'll be interesting to see what effect Coherent has on the UNIX market. --rlw
From: Kenneth Porter 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 common "$$" 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
scriptfile=`tmpname`.sql
you would use
scriptfile=/tmp/$$.sql
It's also common in Bourne shell scripts to use the trap command to delete the temporary file in the event of an unexpected process termination:
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, hangup, interrupt, pipe, terminate). One additional comment: Finding a temporary name by looking for a file name that doesn't exist is somewhat dangerous if two processes could be using the same routine to make such a name. By encoding the process number into the file name, the possibility of collision is 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 files, you should also encode the hostname or network address into the file name. Note that using the pid of the tmpname program is not appropriate, as two programs running a short time apart could end up with the same pid. The pid of the script should be used.
Kenneth Porter Leor replies: Probably the "main" reason is that 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 few characters of the filename. That way, if a file does get left lying around in /tmp, you can easily identify the application script responsible (and probably fix it by adding a trap command such as in your example). 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 you construct the filename using $$; in all but the most obscure cases (such as when there may be a variable number of temp files generated) 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 cases. 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 I want to let you know how pleased I am with the direction you're taking Sys Admin. I'd also like to second Jim Wojno's suggestion (in his letter printed 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 the mechanics and pitfalls of installing some of the common free software packages (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 the bottom up.
Thanks, Well, we'll try, but porting raises some interesting editorial questions. For example, I recently recompiled MicroEmacs ver 3.11 (from the C Users Group Library) to run a Xenix machine. MicroEmacs is carefully written to compile in several environments, including VAX, Amiga, Xenix, and UNIX. Unfortunately, changing the appropriate #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 begin? 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, perl, and awk, are appropriate. We'll try to find a happy balance that still addresses portability. By the way, if you are trying to install MicroEmacs, there are several fields missing from the term data structure defined in unix.c. Compare it to the structure defined tcap.c to find the missing fields. --rlw
From:
uunet!TRONDHEIM.set.nd.no!Peter.Varlien In the July/August issue, Russ Hill asked for, among other things, articles about configuring routers. There was an article called "Building Internet Firewalls" in the February 1992 issue of UnixWorld that addressed this issue. I found it quite informative.
Regards, Thanks for the pointer. -- rlw
|