Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'How to avoid these problems' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
How to avoid these problems
Authored by: nxg on Jul 25, '05 08:02:41PM

There's a lack of defensiveness all round, here!

First, there's no reason for Canon to avoid any particular scripting language (though csh is probably a bad choice on other grounds) -- that's not the problem.

Second, having the customisations in .cshrc isn't the problem either. Customisations that should be in place for each instance of a shell _should_ be in .cshrc (or .bashrc), not in .login, which is (supposed to be) for one-time settings, immediately after the login. As others have pointed out, however, the distinction is blurred in OSX. Whether or not aliasing rm to 'rm -i' is a good or bad thing, folk writing installer or other scripts should be prepared for the user to do this and much worse.

So how is this sort of problem avoided?

From a user point of view, it's good defensive practice to put something like

# csh
# skip remaining setup if not an interactive shell
if ($?USER == 0 || $?prompt == 0 || $?TERM == 0) exit

or

# *sh
if [ -z "$PS1" ]; then
return
fi

...near the top of your .cshrc or .bashrc, and crucially _before_ anything which prints anything to the stdout -- that's another category of hard-to-find bugs avoided. The same goes for system-wide csh and *sh startup scripts. This alone would probably have stopped the original poster being bitten by this bug.

Because being vulnerable to user customisations _is_ Canon's bug, and it should probably be reported to them as such. Mistake number 1 was (as has been pointed out already) not including the -f option in the !# hack in the first line. Mistake number 2 is not carefully unaliasing, or escaping, or using a full path for, any and all commands they use in the script. Avoiding either would probably have been enough, but it's pretty amateur for them to make _both_ mistakes, when writing a script for such a context.

Myself, I would claim that writing any script at all in csh is an immediate bug all by itself (the rant <http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/> is well-known, and spot-on), but that's tip for another time.

All the best,

Norman



[ Reply to This | # ]
How to avoid these problems
Authored by: LC on Jul 25, '05 09:40:12PM

Right -- I was going to point out that any decent .cshrc script which defines interactive features (aliases, etc.) needs to have an exit mechanism which bails out early for non-interactive shells. The installer application which launches a user shell is a non-interactive situation. Prior to the exit logic (where you check the prompt variable, and exit or skip if the prompt is not pre-set), the usual action would be to define the command path (set path ...). After the prompt check, you can put the terminal setting commands, command aliases, and other stuff. I thought (from years ago) that the csh (or cshrc) man page does mention this; Larry.



[ Reply to This | # ]