Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!crdgw1!sixhub!davidsen
From: davidsen@sixhub.UUCP (Wm E. Davidsen Jr)
Newsgroups: comp.unix.i386
Subject: Re: UUCP files/directories being removed under SCO UNIX
Keywords: uucp
Message-ID: <1124@sixhub.UUCP>
Date: 10 Jun 90 03:32:24 GMT
References: <45@raysnec.UUCP> <7585@pbhyf.PacBell.COM> <1095@sixhub.UUCP> <1990Jun7.155204.27108@chinet.chi.il.us>
Reply-To: davidsen@sixhub.UUCP (bill davidsen)
Distribution: na
Organization: *IX Public Access UNIX, Schenectady NY
Lines: 49

In article <1990Jun7.155204.27108@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
| In article <1095@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes:

    [ ... ]

| >  Any competent programmer would write 
| >        cd $i || continue
| >to insure that if the cd failed everything would fail cleanly.
| 
| Perhaps any competent programmer that knew about ksh and its
| incompatibility with /bin/sh.  I suspect that at the time that
| script was writtten, competent programmers knew that /bin/sh would
| exit if a cd fails (a wise default, in my judgement).

  You have a good point there. However, stopping is the last thing you
want to do, since that would fail to do some of the cleanup. Perhaps a
better solution (I've had time to think and your input) would be:

    [ -d $i ] && cd $i || continue

  since that works on sh and ksh, and does not stop if there is a file
instead of directory present.

| I'd put the blame on the authors of ksh for the incompatibilites, or
| whoever decided to use ksh to run scripts written for /bin/sh.

  I can't argue with that, I think the ksh default is really dangerous,
since something like

    cd foo; rm *

  Can kill you in ksh!

| Another annoying incompatibility is that "su -c user script" will
| execute user's .profile if user's login shell is ksh, but not with sh. 

  ?? It will execute the profile names in the ENV variable, but I don't
think it does .profile (unless ENV points there, of course).

| This can cause surprising behaviour when the command is run by cron,
| the .profile has interactive commands, and the user changes his shell.

  I'll look at this next week, but I think it's as I mentioned. I tried
it VERY quickly, but I don't claim that I have the definitive answer.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me