yet again Re: crontab Daemon-from-Hell

[Daniel R. Levy]

In article <1545 at sialis.mn.org>, rjg at sialis.mn.org (Robert J. Granvin) writes:
[about uudemon.day]
> The solution is VERY simple.  Remove the `cd`, and make the find
> reference an explicit path.  If the directory dies or goes away, the
> find will fail, and nothing more will happen than your uucp mailfile
> getting a note of the failure.

Could someone please tell me if my postings on this group are getting out?

Twice this past week I mentioned that a failed 'cd' (due to, for example,
the directory named as the argument to 'cd' not being present) would ABORT a
script running under /bin/sh, uucpadm's default shell.

This is UNLIKE what happens in an interactive shell session, where the shell
does not abort upon a failed 'cd' but simply stays in the directory where it
was before the failed 'cd'.

Unless there is some reason that the uudemon.day isn't running under stock
/bin/sh (e.g., you installed your own version of /bin/sh which does not
abort scripts upon a failed cd, or installed /bin/ksh in place of /bin/sh,
or gave uucpadm a shell of /bin/ksh in /etc/passwd [why? when it's not
an account meant to be logged into directly]) there is NO DANGER of the stock
uudemon.day wiping out anything other than 30-day-old contents of
/usr/spool/uucppublic.  Please folks, don't holler at AT&T for this....

I apologize for sounding exasperated.  I assume that my posts just haven't
gotten to Robert's site yet.  Are they getting out at all?
-- 
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.