[ncolug] Re: Linux Home Automation
- From: Chuck Stickelman <cstickelman@xxxxxxxxxx>
- To: ncolug@xxxxxxxxxxxxx
- Date: Sat, 15 Dec 2007 22:51:20 -0500
Mike wrote:
> Mike wrote:
>
> Replying to myself...
>
> I walked away and figured out I gave out conflicting information. Use
> mktemp, then you won't have fuss with the file names. They are
> handled there.
>
I've never worked with mktemp... Sounds like a tool I /will/ use from
now on! Thanks, Mike!
> The date info still applies IMNSHO if you are creating the files.
>
No need for false humility here, Mike. You're right in time stamping
your temp files.
> Commented on testing for the existence of files and/or redirecting
> output. One can redirect STDOUT and STDERR in the crontab file. This
> will prevent you getting mail if any output is generated. This isn't
> the best thing to do unless the output is meaningless. I like to have
> the script catch any output or redirect it, then if something goes
> awry during a run of cron you will get a mail that will be useful.
>
> Other tidbits more applicable to multi user systems. Quit using ~/bin
> for other than test purposes. Ask Chuck for a dissertation on the
> headaches this will cause you, and to why it is a very bad practice.
> I'm not going there.
>
Does anyone want to hear about this? The short answer is that a script
like this belongs in /usr/local/bin/.
> I'd also use /tmp or /var/tmp for the files, again not ~/something.
> Using either should include a test to ensure that the directory exists
> before trying to write files to it. Yes it is a bit more work, it
> goes back to using ~ again.
>
Creating temp files MUST ALWAYS be in a directory that has it's
sTickybit set! ALWAYS!! (Can we assume that /var/tmp always exists?)
A roust script will always test instead of assume. Think about how it
could fail, and what would/could cause it to fail, and test for those
conditions. Most software bugs stem from programmers making assumptions.
> A script this short I probably wouldn't do the following on Linux.
> Other *nix systems I would. I do this because I want to know
> *exactly* what tool I'm calling. On the Solaris boxen at MSC one
> could find up to 4 different versions of a given tool. It ain't
> pretty when you get the wrong one due to a PATH issue. All that said,
> what I do is set variables for each tool called and then reference the
> variable. Something like this.
>
> LS=/usr/local/bin/ls
> RM=/bin/rm
>
> ${LS} -1 /somedir/* | ...
>
> I also tend to get rather anal and use ${} when using variables.
> Certainly not required, it helps me with readability and there is some
> reasoning to the usage in my brain.
>
Great suggestions! Especially true on the "GNU/Solaris" boxes we ended
up with at MSC...
> Mike
>
Chuck
Other related posts:
