Path: utzoo!utgpu!watmath!uunet!cs.utexas.edu!rutgers!tut.cis.ohio-state.edu!att!cbnewsc!levy
From: levy@cbnewsc.ATT.COM (Daniel R. Levy)
Newsgroups: unix-pc.general
Subject: Re: crontab Daemon-from-Hell
Message-ID: <1128@cbnewsc.ATT.COM>
Date: 5 Jun 89 04:23:54 GMT
References: <19071@cup.portal.com> <14373@bfmny0.UUCP> <1526@sialis.mn.org> <694@galaxia.Newport.RI.US>
Organization: AT&T Bell Laboratories, Skokie IL
Lines: 22

In article <694@galaxia.Newport.RI.US>, dave@galaxia.Newport.RI.US (David H. Brierley) writes:
< >>>	cd /usr/spool/uucppublic
< >>>	find . -type f -mtime +30 -exec rm -f {} \;

< If you execute a 'cd' command to a directory that
< does not exist the only thing that happens is that you get a stupid little
< error message.  If your current directory is '/', which is normally the case
< for the 'smgr' process, and you execute the two commands listed above, and
< for some reason the 'cd' command fails, this will have the effect of wiping out
< every file on your machine which has not been modified within the last 30 days.

This only happens if the commands are entered into an interactive shell session.
If they are in a script being run by /bin/sh, a "cd" that fails will abort the
script (O.K., will abort the shell running the script).  Korn shell (/bin/ksh)
will not abort, however, on a failed cd in a script.  This is a feature to
permit recovery from inability to cd somewhere but for the unwary script-writer
it can cause trouble like the above....
-- 
Daniel R. Levy             UNIX(R) mail:  att!ttbcad!levy, att!cbnewsc!levy
AT&T Bell Laboratories
5555 West Touhy Avenue     Any opinions expressed in the message above are
Skokie, Illinois  60077    mine, and not necessarily AT&T's.