[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: When to trust compound statements and when to test? was: restart all services?



On Sat, 08 Jun 2002 22:00:07 -0500, Derrick 'dman' Hudson wrote:

>On Sat, Jun 08, 2002 at 07:41:30PM -0500, Gary Turner wrote:
>| On Sat, 08 Jun 2002 15:07:10 -0700, Karsten M. Self wrote:
<snip>
>| 
>| Is there a rule of thumb to determine when sequential commands should be
>| trusted and when  they should be tested? 
>
>The result should be tested when you care about it.

Oops, obvious answer for a simplistic question :) The problem still
exists, when should I care?  See your next comment.

>
>| In the above example, if the
>| stop command does not exit 0, is any harm done by going into the start
>| command?
>
>Probably not.  In fact, sometimes that is desired -- the stop command
>will often exit with an error status if the daemon wasn't already
>running, and in this case you want to start it again anyways.

Interesting point.  I had not thought about that in this context.  In
this case, I don't need to care.

>
>| What should I look for that would suggest the need for testing; eg.,
>| "do $file stop && $file start;"  The possibility exists (citing
>| extreme shell ignorance) that I'm totally off base even bringing up
>| the question.
>
>You look for the situation where an error in an earlier command means
>that you shouldn't execute the second command.  It all depends on what
>the commands are and what the errors mean and what you want to do
>about them.

Yeah, you mean RTFM, don't you?  I'm not comfortable with what's going
on in many of the shell commands, and their full consequence.  I'm a
poor enough programmer (C++) that I tend to [over?]test (at least during
initial coding) for expected results.

Thanks, dman, for taking the time here.  Just about the time I'm feeling
comfortable on one level, something jumps up and bites me on the butt.
And that, my friend, creates paranoia.
--
gt
Yes I fear I am living beyond my mental means--Nash


-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: