fault toleratant shell scripts

[Bill Vermillion]

On Mon, Mar 15, 2004 at 11:40:59AM -0500, Walter Vaughan thus spoke:
> I just ran across this. I'm not even a newbie-level
> shell scripter, but this makes huge sense to me...
> http://www.cs.wisc.edu/~thain/research/ftsh/

> The manual is does a better selling job
> http://www.cs.wisc.edu/~thain/research/ftsh/ftsh-2_0_3/doc/ftsh.html

The first example they give, about a failed cd was seen long ago
in the Bourne shell.

Regular cleanups of lost+found were scheduled on a system, and
somehow lost+found was deleted.

So when the cd /lost+found failed, the following command
rm -r * was performed on / with the resultant anguish.

That was fixed a long time ago - this was pre free *n*x systems.

In an older version of the Bourne Again Shell [bash] there was
a problem with tabbed file name expansion, where as I recall
if you performed an rm on a symlink, and used tab expansion
instead of typing the name instead of linkname, it expaned
to linkname/ with the consqeunce of removing the files
in the symlinked directory instead of removing the symlink.

The /bin/sh on this system take an -e argument which will exit
the non-interactive shell on failure of any piece.

The problem we have now is there are so many shells avaiable for
use.  This system shows 29 different choices in the ports
hierarchy.

> I especially like the time and cycle limits.

Good ideas.

> I have not used, nor installed, but I am sure someone
> on this list has needed something just like this for ages.

One problem is getting users to realize that there can be problems
with some shells and for scripting you use the most robust you can
find.  Most shells seem to be chosen with interactive use in mind,
and that doesn't mean they have been thorougly tested or are robust
enought for interactive use.

The good thing about the shell in the link is that it is GPL, and
thus hopefully will show up everywhere.  I've been using ksh for
years - dating back to the time you had to regiester at AT&T to get
the downloaded pre-compiled binaries for your OS before they began
making the sources available.

Hopefully the word of the above will spread, and if nothing more,
will make writers of scripts more aware of potential system
destroying chances.

Writing the scripts so they don't execute under the root privledge
and thus not be able to remove system files is something that is
not often considered. And for scripts that need to be run as
root to be really sure you don't accidentally nuke your system
you should make all the system files and directories immutable -
but that is OS dependant - but it does mean that even root can not
remove those files unless the immutuable flags are removed.

Depending on security levels removing immuteable flags sometimes
means rebooting to single user maintance, and then performing the
changes there.

Bill

-- 
Bill Vermillion - bv @ wjv . com