This is why I really like this list... All of these tips are fabulous, and I intend to re-write the script incorporating many of the design ideas described. Since Mike raised the issue, why is it bad to use a ~/bin directory? This script is a bad example, as the actions of this script inherently affect all users of the system. In production use (and my next revision), I would put the script in /usr/local/bin. But, I have several scripts which are just short one-line scripts for recalling some of my personal internet radio streams. For those items which are designed by one user for that user to only, would it not make sense to place the files in the user's home directory? Or did I miss a chapter of the FHS or something? ;-) The new revision will include mktemp directories and placing them in /var/tmp. I like the idea of having all of the files located in a designated temp directory. The output is definitely something I would keep. I just don't want cron reporting the success output of 5 pings every 5 minutes... ;-) So, I dumped that output. If anything else goes wrong, I will get the message. The serial device permissions, I am not worried about. The perms on /dev/ttyS0 are 660 with root:dialout. My user belongs to the dialout group. Since no dial-up modems are in use here and never will be on this device, I might remove all users from dialout, add nobody to that group, and run the script from nobody's crontab. Rob On Dec 15, 2007 8:01 PM, Mike <mikeb@xxxxxxxxxxxxxx> wrote: > Rob Gibson wrote: > > #! /bin/bash > > > > ping -c 5 www.google.com &> /dev/null || echo "FAILURE" >> ~/.x10/$(date) > > if [ $(ls -1 ~/.x10/ | wc -l) -gt 2 ] > > then > > br -x /dev/ttyS0 X15 OFF > > sleep 5 > > br -x /dev/ttyS0 X15 ON > > rm ~/.x10/*200* > > fi > > Two things I'd likely add would be the use of trap and mktemp. The use > of mktemp will help with regards to a race condition and the possibility > of someone overwriting files as you mentioned. Using trap in a sane > manner will keep things cleaned up if strange things happen. Not that > likely in this case I'd say. > > I think I would also change the file name created to something like this. > > date +"%Y-%m-%d-%M%S" > > This format is an ISO standard, won't create file names with spaces, and > will also sort in a sane manner. Now much of this doesn't apply here, > it's more about being consistent. This will help later when you look > back to something and try and figure out what you were doing. > > > I am also using the extra lamp module to connect the lamp near the > > door to the x10 system. > > > If anyone sees any other improvements or suggestions which could be > > made, I would be most appreciative. > > > > Thanks, > > Rob > > What about the perms on the serial device? Obviously you can read/write > to it. Maybe br is setuid? I don't recall. This could open up it's > own set of problems. > > Next months project, break into Robs' box, then setup something to flip > that light off and on at arbitrary times. :) > > Oh yes, looking back at the script. Since this will be running from > cron you may want to consider adding a test. The test would be in the > then portion of the if statement. I would test to ensure that files > actually exist before removing them. Or redirect STDERR to /dev/nul. > Otherwise cron is going to be mailing you with output. Granted it > shouldn't happen. Experience says, even if it shouldn't happen, it will. > > Looks like a nice setup and a good example to build on. > > Mike > > > To unsubscribe send to ncolug-request@xxxxxxxxxxxxx with 'unsubscribe' in the > Subject field. > > To unsubscribe send to ncolug-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field.