New Messages
From: Michael Faurot <bogart!mfaurot@uunet.uu.net>
Hi Leor, Well, looks like the typesetting has a few bugs to be worked out over there. :-) In the article on pg. 110 it shows the following line:
isql phone - < EOF 2&1 | more
Actually it should read:
isql phone - << EOF 2>&1 | more
Could you ensure that something gets sent out in the next issue showing the line as it should read?
Thanks. Leor responds: Thanks for writing. Ventura sometimes does this to us.
From: csusac!ulysses.att.com!cjc Hi, I just picked up a copy of Sys Admin yesterday, and have some comments (mostly nits to pick) Larry Reznick's article. First, a nit to pick... in the sidebar on '[' vs 'test', I thought it kind of odd that the article stated that the two were linked. While it's true that older versions of the Bourne Shell had test as a separate program, _all_ modern implementations have it as a built-in, so it would have been better just to say that they are synonyms. The other nits I have have to do with the 'which' script. The first and most obvious problem with this script to me is that it bothers to convert the ':'s to ' 's, when the IFS variable could do the job even better. Not only that, but it is _possible_ that one of the directory names could contain a ' ', making the script incorrect. The other one is that I'm appalled each time I see something like
if [ "x$1" = "x" ]
This is _much_ easier to understand as either
if [ -z "$1" ]
or even
if [ "$1" = "" ]
Well, at least the script didn't use
if [ x$1 = x ]
which I've seen all to often. In this case, there's also the problem of the script aborting early if one of the arguments is blank. For instance, in the case of
which '' id
id will never be gotton to because the program does tries to find the last argument by noting that it's ''. Using $# is clearly the right way to go. Finally, the program merely checks that the files it's looking at are executable, but doesn't check that they might be executable directories. My revised version is below.
#!/bin/sh # # which # # based on which by Lawrence S Reznick (Copyright 1990) as printed in # SysAdmin magazine. # revised by Christopher J. Calabrese (cjc@ulysses.att.com) if [ $# = 0 ] then echo "usage:\t$0 program [program] ..." exit 1 fi dirs=`echo $PATH | sed ' s/^:/\.:/ s/:$/:\./ s/::/:\;:/'` unset notfound while [ $# != 0 ] do unset found oIFS="$IFS" IFS=":" for dir in $dirs do if [ -x "$dir/$1" -a ! -d "$dir/$1" ] then echo "$dir/$1" found=true break fi done if [ -z "$found" ] then notfound="$notfound $1" fi shift done if [ -n "$notfound" ] then echo "No $notfound in " `echo $dirs | sed 's/:/ /g'` fi
Christopher Calabrese There are versions of test internal to sh, csh, & ksh, all with essentially the same test features, but with differing syntax. I have also seen [ as a hard link to the external test program. To give you an idea of how varied this can be just on two systems, on SCO SVR3.2v4, there are two unlinked files for [ and test. Each is a Bourne shell script that manually starts the internal test program named for the script. On Esix SVR4 there is no [, and test is a Bourne shell script invoking the internal test program. But, it invokes it by using `basename $0`, so if a [ hard link was there, it would use the internal test or [ synonyms according to the name used to execute it. I imagine that the external test program still hangs around to support old scripts that want it that way. I've seen it implemented too many different ways. The sidebar mentions one way I've seen it that takes up the least space yet still has the external program. Your IFS solution is more elegant for the loop, but I notice that you still need to convert the colons to spaces for the error message. While you have deferred the conversion until it can't be avoided, which is commendable for efficiency, you still have to launch sed to do it. I decided to just launch sed and get everything over with at once. (I noticed you have a semicolon typo in the third sed expression. It should be a period.) As for directory names containing a space, that sin is not easy to commit by the average user. If I ever saw that actually happen, I'd track down the owner, find out why and what depends on it, and rename the offending directory as soon as I can. By the way, you don't need to store the oIFS since the IFS change won't affect scripts that aren't children to the which program. Notice that you don't restore from oIFS. Your other comments are correct. The test techniques were holdovers from a very old version of this script when I knew less and was probably in an unreasonable hurry. I neglected to update them when I rewrote this for SCO. Not checking for directories with the executable bit set was an important oversight pointed out by another reader. I plead only that the dirs in my path haven't had executable directories with the same name as the program I was looking for, so I never caught the problem. Thanks for your version of the code. --lsr
Sys Admin staff, I would appreciate your help as I have two brand new terminals and cannot use them for multitasking.
Joe Cao Contributor Larry Reznick responds: SCO provides multiscreen for the console, and mscreen for serial lines. Esix supports virtual terminals only on the console. SVR4 doesn't support virtual terminals at all. Therefore, I don't believe the problem has anything to do with Wyse. It must be related to the particular implementation you're using. I'm not familiar with the Arnet software. The virtual terminals I've set up require respawn entries in the /etc/inittab for the virtual terminals. The entries put a getty on each virtual terminal device entry I want to enable. Furthermore, the kernel may need to be remade to support them. A total-used count is given to the appropriate device drivers. Once the virtual terminals are set up, I've never had a problem with switching between screens. Tasks left in other screens continue to run, including output on the switched-out screen. Switch back to that screen and it looks exactly as if you'd never switched it out. If Arnet's implementation requires the output screen to be active, they've effectively eliminated the usefulness of multiscreens. If you can't get Arnet's multiscreens working properly, you could have a script run the program that creates the output file, then enqueues an "at" job that will kill the file at some later time. --Larry
From: David Drexler I recently received my first issue, and it looks to be worth its weight in 486 chips. The Publisher's Forum note say that this is an anniversary issue. That means there are 6 issues of it I haven't seen yet. Where can I get them, and what will they cost me?
David Back issues are available for 1.3 (Sept/Oct '92), 1.4 (Nov./Dec. '92), and 2.2 (March/April '93). They can be ordered from R&D at a cost of $11.00 per issue (US).
From: Chris Hare <unilabs.org!chare@uunet.uu.net>
Dear Robert: The current release of SCO UNIX is release 3.2 Version 4, not 4.2. Yes, you are correct that it is still based upon version 3.2, which is the first USL release which was meant to incorporate binary compatibility between Intel UNIX versions. The Version 4 is SCO's attempt to show the lifeline of the product. It initially started as 3.2, and then 3.2 Version 2, and now Version 4. The reasoning behind this is simple. When you look at SCO's product line right now, they have integrated UNIX, Security, Multiprocessing Extensions, X windows and the Desktop, and Networking. In fact, SCO has been doing Multiprocessor UNIX on Intel platforms longer than anyone else, and their latest MPX software provides for true symmetrical multiprocessing. At the time Release 4.0 was announced from USL, there was a separate source code tree for each of these which would have to have been re-integrated by SCO. Their thought at the time, rightly or wrongly, was to stay with the 3.2 release until USL had integrated all of these components. You are quite correct that the version numbering has confused a lot of people, but then it is all marketing. Take a look at how many people will be buying Windows NT when it hits the streets, and no one has seen it yet! This is true for Release 4.0. So much effort was put into the marketing, that people were persuaded to get it even before it was a product. We all have to remember that USL desgins technology, not products. Those are for the vendors like SCO to assemble from USL based technology. In addition, Veritas does have volume management software for SCO UNIX, and we have put some of it into some customer sites, most notably at Bell Cellular, which is one of the Cellular telephone networks here in Canada. They are using SCO UNIX and Veritas for voice-mail storage, call-record storage, communications with the mainframe where the costing routines are run, and the actual cell switches. I would be happy to send you a copy of the information which I have on it. Finally, congratulations on your anniversary. I feel proud to be associated with your organization, both as a subscriber, and an author. Keep up the good work!
Chris Hare Robert Ward responds: Thanks for the clarification -- and for your good work as an author! Editor's note: Although Bjorn Satdeva has included information about SAGE (The System Administrators Guild) in his column, we thought Ready Holt's letter would be useful to many of you.
From: Randy Holt <rholt@eagle.dazixco.ingr.com>
Hello, I have discovered a group of mail lists that can benefit the few, the proud, the System Administrator! I believe publishing these lists in Sys Admin magazine will help widen the distribution. Please do not look at this as competition, but as a partnership. The aliases I am referring to are the SAGE (System Administrators Guild) group of USENIX aliases. Here is a listing followed by a short description of a select few. I hope you decide to publish this information.
Randy Holt Here are instructions for the Administrator to subscribe to an alias: **** Help for Majordomo@USENIX.ORG: This is Brent Chapman's "Majordomo" mailing list manager, Revision 1.46. It understands the following commands: subscribe [address] -- Subscribe yourself (or address if specified) to the named . unsubscribe [address] -- Unsubscribe yourself (or address if specified) from the named . which [address] -- Find out which lists you (or address if specified) are on. who -- Find out who is on the named . info -- Retrieve the general introductory information for the named . lists -- Show the lists served by this Majordomo server. help -- Retrieve this message. end -- Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of an email message to "Majordomo@USENIX.ORG." Commands in the "Subject:" line NOT processed. If you have any questions or problems, please contact "Majordomo-Owner@USENIX.ORG." Index: sage sage-bof-scotch sage-certify sage-chairs sage-conf sage-edu sage-ethics sage-jobs sage-locals sage-managers sage-nominations sage-online sage-outreach sage-policies sage-pr sage-pt sage-pubs sage-robbies sage-security sage-stds sage-vendors sage-wheel A Few Descriptions sage-certify Welcome to the SAGE certification working group. The purpose of the certification working group is to develop a model for the certification of system administrators. The model will address the issues surrounding certification and discuss the various approaches that might be taken. The working group will present the model along with their recommendations to the board of directors. sage-conf Welcome to the Sage-Conferences discussion list. This mailing list is for the SAGE members (or potential members) who are interested in conferences and workshops to be run by or in association with SAGE. sage-edu The Education working group's initial goal is to outline SAGE's plan for institutional and continuing education of the community through the development of model curricula, the identification and promotion of useful tutorial programs, and the construction of guides for self-study. sage-ethics This group is charged with determining SAGE's role in developing a set of guidelines or codes of ethics for the system administrator. We see these guidelines or codes as having at least two purposes, namely, guiding one's self in the performance of system administration tasks, and informing one's employer and co-workers of the proper bounds of system administration. sage-jobs Welcome to the SAGE Job Descriptions Working group! The job description group will evaluate SAGE's role in assisting system administrators with defining job descriptions. If it is determined that this is an area that SAGE should pursue, the focus of the group will be to create multiple system administration job description suites that can be used as templates for those who are writing position descriptions for hiring purposes at their own site. info sage-locals Welcome to sage-locals. Users can be friend of the system administrator, but will never be able to be a peer. Therefore many system administrators are working without contact to their peers. SAGE local groups is intended to give system administrators to meet on a regular basis. The purpose sage-local small working group is to define relation ship between local groups and SAGE. As SAGE is a USENIX STG, this will include relationship to USENIX. The group will also have the task of explore how creation of new local groups can be made easier, and how SAGE can support existing local groups, like Bay-LISA and BackBayLisa. sage-managers Welcome to the sage-managers mailing list! While the complete new-subscribers information is currently under construction -this brief is available. Sage-managers mail list was put together to provide a forum for those people wishing to address the issues of systems administration and managin or being managed thereto. This includes, but is not limited to (in true management wording fashion): how to provide the right kind of supporting information to management; how to explain systems administration so as to get what you need and not bore your boss; can someone talk to my manager and explain to him whatinhell is going on . . . and others. All the details of what this means or what we-all have energy for have not been hammered out. I will have a one-liner (or thereabouts) charter in place after Turkey day. Then we can free for all. sage-online The electronic information distribution working group will identify existing information sources that would be of use to SAGE members, new types of information that should be gathered/produced, and make proposals for the effective distribution of this information. Existing sources should include reprints of papers/articles and mailing-list/USENET news archives. New information sources might include specially written technical/positional papers and custom databases such as vendor neutral list of bugs. Distribution methods will include WAIS or other information servers, anonymous ftp/uucp, and CDrom. sage-outreach This mailing list is for discussions pertaining to the sage-outreach working group. This group will make a proposal to the SAGE board on how SAGE can address the needs of system administrators who deal with heterogeneous environments, which include systems running many different OS's. Additional items may include how SAGE can best contact these people, who may not be plugged into the traditional UNIX(tm) oriented communication channels. sage-pt The Part Time working group is concerned that the proposed SAGE charter did not mention the large number of people who do system administration less than 100% of the time. (e.g. There are chemists who fulfill system administration roles some portion of each working day. Yet, view themselves as chemists, not system administrators. Hence, part time system administration.) We will consider how SAGE could address the needs of such individuals and propose changes to the proposed SAGE charter which addresses this "dual-role" reality. sage-pubs The publications group is chartered to put together a series of proposals related to the various publications that SAGE wants established. In the immediate future the pubs group will be asked to assist in the publication of the first issues of newsletter segments within "login:". Long term goals include proposals concerning an independent newsletter, a technical journal, software tool collections, and any other ideas the committee can collect. sage-stds This is the USENIX SAGE Standards Working Group mail reflector (sage-stds). The purpose of sage-stds is to provide a forum for discussion about system management standards in the following areas: Communication: Provide a central point of contact for information regarding system management standardization efforts. Education: Educate system administrators about the standards process in general. What can active administrators do to progress standards. Participation: Provide a conduit for the solicitation of input from active system administrators. Most standards participants represent OEMs. More input from active system administrators is needed. Summaries will be posted to the mailing list of the IEEE POSIX activities, OSF ManSig activities, UI SMWG activities, as well as X/Open and NM Forum activities as they are publicized. If you would like to sign-up as the "official" reporter for a standards working group, please post to sage-stds@usenix.org, and we'll sign you up. sage-vendors Welcome to SAGE vendors working group! The purpose of this list is to discuss ways in which we, the members of the system administration community, can encourage vendors to recognize the importance of system administration and the need to develop tools to facilitate this. Often times a single vendors' "solution" to system administration has no application in the real world, where many of us employ the hardware and software of several different companies. It is hoped that SAGE can provide sufficient leverage to get vendors to provide real world solutions that we would actually want and could actually use. Initially the purpose of the list will be to discuss the feasibility of this course of action, and make a recommendation to the SAGE board. The board will then decide whether or not to pursue any sort of interaction with hardware and software vendors. However, the list is not limited to the purposes stated above, or to my personal view of what the vendor group should focus upon. You, as a member of the group, have a great deal of say in the matter. If the members of the list feel the group should take a different direction, that's what the group will do, provided it remains within the scope of our charter.
|