New Messages
Please send letters via email to saletter@rdpub.com.
Subject: Uptime Reporting (Gray, Sys Admin, 5.1) First, in several of his shell scripts (sysmon, cdl, cml, and rmu), Gray presents a poor design for obtaining the pieces of the date (month, day, etc.): He calls date, saves the result in a file, and then calls cut not once but *six* times. A better way (the best way?) to do this is as follows:
# Save $1 from the command line cmd = $1 # Break the date into pieces set `date '+%Y %m %d %H %M %S'` YY=$1 MM=$2 DD=$3 HH=$4 MN=$5 SS=$6
Notice that this also avoids a call to expr, which Gray could have also done by specifying %Y instead of %y in his call to date. My second concern is that this extended manipulation of the date begs the question of why is it being done at all? In the program rst.c, Gray goes to considerable length to convert the dates back to seconds, when this is already the base form of time on UNIX systems! Wouldn't it have been easier to write a (very) small C program that emits the results of time() (or gettimeofday(), as appropriate)? Last is my concern about "user design": Gray has chosen to present his uptime statistics in seconds! Quick -- how many seconds in a day? In a week? How many days (weeks) is 2591097 seconds? The only useful number in the monthly report is that of uptime expressed as a percentage. Surely he could have done the extra arithmetic and produced reports in some or all of weeks, days, and hours. You would have a hard time convincing me that Mr. Gray's "customers" *asked for* the reports in units of seconds. This is just another example of the low standards your publication sets for itself; I would have been embarrassed to have produced a system such as Gray's, let alone submitted it for publication. I will be quite surprised if you print this letter: You didn't print my previous one, nor does your publication strike me as one that is willing to print letters of dissent, but I had to write anyway.
Adam Moskowitz The overall philosophy of the package, as stated, was to get something going in two weeks (with all the other activities that sysadmins have to deal with as well). The initial recommendation was to buy a package. When that was turned down, I went ahead with incremental development -- make a piece; check it out; plow ahead. I did not go back and revisit chunks already built to make it more efficient -- it was constructed ad hoc as I went along. Literally, I built it a few lines at a time by running sh -x and watching. There was no grand implemention design. That was part of the point: you can do a quick job with sh. The other point was the utter simplicity of keeping the record. The source is free for those who want to improve it; Mr. Moskowitz is welcome to it, as are the 15 or so others who have downloaded it. If an installation needs more than the elementary statistic offered by this code, my recommendation would be the same as the one I started with -- buy a package.
Thanks. Mr. Moskowitz -- Not only am I printing your letter, I'm going to thank you for writing. You are right about the coding: I'm embarrassed I didn't catch it. Just as some musicians sight read well and some don't, I would far prefer to write code than read someone else's. Thus, I often read the text more carefully than the code. In prior months, since I was also functioning as CEO of a 40-person company, there were times when we printed stories that I didn't read at all. I think the central idea of this story -- a simple uptime reporting mechanism -- is useful, even clever. I have to admit, though, that I agree with your evaluation of the implementation details. Even so, printing the code isn't without merit. I'll bet there are a lot of sys admins who, as a result of reading this exchange, will have a much clearer idea of how to proceed next time they need to manipulate a time. Thanks for writing. I depend upon my readers to keep me on my toes. -- rlw
|