Path: utzoo!attcan!utgpu!watserv1!watmath!uunet!wuarchive!psuvax1!rutgers!umn-d-ub!umn-cs!nis!sialis!rjg
From: rjg@sialis.mn.org (Robert J. Granvin)
Newsgroups: unix-pc.general
Subject: Re: ln ksh /bin/sh (was: second disk partitions on UNIXPC)
Message-ID: <2077@sialis.mn.org>
Date: 8 Dec 89 04:49:48 GMT
References: <1717@mtunb.ATT.COM> <12086@cbnews.ATT.COM>
Reply-To: rjg@sialis.mn.org (Robert J. Granvin)
Distribution: unix-pc
Organization: Dr. Ho Laboratory and Day Care Center
Lines: 51

>With all due respect for John McMillan and his useful postings, I must admit
>to having made ksh my standard /bin/sh years ago and, so far as I can tell,
>have experienced only one bad side effect: 
> [...]
>If anyone actually has an example of ksh breaking a command, etc, I would
>really like to hear about it.  Please send me the particulars so I can try
>it on my system.

It's not necessarily bad on the command level, though it could be, but
it can be "bad" on the operational level, as an example earlier.

To clarify, consider this two line sequence (this was the source of
much "discussion" several months ago):

cd /usr/spool/uucppublic
find . -type f -mtime +30 -exec rm -f {} \;

These lines are found in the /usr/lib/uucp/uudemon.day script of the
original (Vanilla) UUCP distribution.  Ignoring the original hype,
paranoia, oopses, goofs and doomsaying that brought, the problem here
is basically:

What happens if /usr/spool/uucppublic goes away?

If it's running under /bin/sh, nothing.  You'll get a message in your
mailbox, and the script will stop.

If it's running under /bin/ksh, the cd will fail, you will stay in
your defined "home" directory, and the find will continue.  In the
case of uucp, this will cause little or no damage.  But consider if it
was run as root (which I've also seen people use to run their UUCP
crons(*))... Your home directory would be /, and nothing would be safe.

It can also be counter argued that the success or failure of a cd
should be checked, which is a valid point.  But it's simply a
misunderstanding, or lack of understanding, of how ksh differs from sh
that can get you into trouble.

Likely to happen?  Probably not.  Impossible to happen?  Never.

Although I'm quite interested in knowing how else ksh differs from sh.
Some of this has already proven to be valuable knowledge.

(*) No comments from this quarter about people who run their
administrative crons under root and have ksh as default.  Erf.  :-)

-- 
________Robert J. Granvin________        INTERNET: rjg@sialis.mn.org
____National Computer Systems____          BITNET: rjg%sialis.mn.org@nic.mr.net
__National Information Services__            UUCP: ...amdahl!bungia!sialis!rjg
 "Insured against Aircraft, including self-propelled missiles and spacecraft."