On Sun, Jun 09, 2002 at 01:02:11AM -0500, Gary Turner wrote:
| 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.
:-).
| >| 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?
Sort of.
| 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.
The decision requires a human to evaluate the situation and decide
what the proper course of action is, then instruct the computer how to
do that. Take a simple example -- you want to rename all the files in
a directory (say .htm to .html). Also suppose you didn't know about
the 'mv' command, or couldn't use it for some reason.
for F in * ; do
cp $F ${F}l ; rm $F
done
In this snippet I don't check for 'cp' exiting with an error. Here it
is really bad to go ahead and remove the original when it has yet to
be copied. (suppose you ran out of disk space or something, or didn't
have permission to write to the destination) In this case, as an
intelligent human, you have to decide that running 'rm'
unconditionally is bad and that it should only be done if the 'cp' was
successful. A better way to write that (still ignoring 'mv') would be
for F in * ; do
cp $F ${F}l && rm $F || echo "Warning, $F not renamed."
done
This is no different from C++, except that C++ has exceptions (which
makes the code for error handling a little different) and you call
functions rather than whole programs. If you think of each shell
command as a function, then it's much like C programming (check the
return value).
Sometimes you can't reasonably handle the error condition at that
level and so you want to propagate the error upwards. In C++ (Java,
Python, Eiffel) that simply means not catching the exception. In a
procedural language (C, sh) you must explicitly check the error code
returned by the function/command you called and explicitly return an
appropriate error code to your caller. In a shell script this can be
made convenient with the
set -o errexit
option, but that isn't always applicable.
| 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.
C++ is a large and complex language which also embeds two other
sub-languages, one of which is Turing Complete (templates). It is
easy to get bit in the butt by C++, especially if you aren't
experienced. I recommend choosing a more forgiving environment for
learning/practicing/developing programming skills before tackling C++
(if, by that time, you still feel inclined to :-)).
-D
--
The crucible for silver and the furnace for gold,
but the Lord tests the heart.
Proverbs 17:3
GnuPG key : http://dman.ddts.net/~dman/public_key.gpg
Attachment:
pgpnZEHq8b0wc.pgp
Description: PGP signature