Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!decwrl!sgi!arisia!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.unix.wizards
Subject: Re: fixing rm * (was: Worm/Passwords)
Message-ID: <754@quintus.UUCP>
Date: 27 Nov 88 06:45:33 GMT
References: <1812@ndsuvax.UUCP> <717@quintus.UUCP> <6518@csli.STANFORD.EDU> <723@quintus.UUCP> <6550@csli.STANFORD.EDU> <1457@unisoft.UUCP>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 38

In article <1457@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes:
>In article <6550@csli.STANFORD.EDU> wagner@arisia.xerox.comP (Juergen Wagner) writes:
>>In article <723@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>>>No, it is _not_ a bad example.  If I "alias ls 'ls -F'", I am likely to
>>>use it in a script which _relies_ on that behaviour.  Then I give it to
>>>someone else and it doesn't work.  THIS KIND OF THING **HAPPENS**.

>For one thing, csh aliases (which seems to be the format of the aliases
>you are describing) are NOT EXPORTED to shell scripts OF ANY SORT.  'ls'
>evaluates to whichever 'ls' is found first in your $PATH.

I don't quite understand what "The Grey Wolf" means here.
Unless you take steps to prevent it, the C shell *does* source .cshrc
when it reads a script (that is, after all, what .cshrc is FOR), and
that is where most people put aliases like that.  (If you put your
"rm", "ls", and suchlike aliases in .login, you're safe.)  You can
tell which aliases will affect C-shell scripts by doing
	% csh -c alias

>If you're going to write a csh script,
>you're better off prefacing it with the line
>#!/bin/csh -f

Indeed you are.  You're even better off not writing Csh scripts.

>With respect to bad practice of re-defining what you want your commands
>to do, it's purely a matter of opinion and subject to debate.

Well, everything is subject to debate.  But "purely a matter of opinion"
is an attitude of despair.  We _can_ approach questions like this
objectively.  We simply have to measure which approach is less likely to
lead to error.  All it would take to determine whether (a) redefining rm
to be something LIKE rm but different, or (b) adding a new command and
deleting rm, or (c) adding a new command and leaving rm alone, or (d)
doing nothing would be better is an experiment which would take a couple
of months, a few dozen people, and money.  Pending such a study (anyone
want to fund me to do it?)  we can analyse the matter logically.  Of the
four approaches, (a), (c), and (d) all permit disastrous mistakes.