Xref: utzoo comp.sys.att:7070 comp.unix.questions:15171
Path: utzoo!mnetor!tmsoft!dptcdc!jarvis.csri.toronto.edu!rutgers!dptg!att!chinet!kdb
From: kdb@chinet.chi.il.us (Karl Botts)
Newsgroups: comp.sys.att,comp.unix.questions
Subject: Re: Forcing /bin/sh in a script under V/386 3.2 Korn shell
Keywords: sh ksh
Message-ID: <9065@chinet.chi.il.us>
Date: 25 Jul 89 06:17:42 GMT
References: <14445@bfmny0.UUCP> <1989Jul12.191342.1048@cs.dal.ca> <14463@bfmny0.UUCP> <1792@cadillac.CAD.MCC.COM>
Reply-To: kdb@chinet.chi.il.us (Karl Botts)
Followup-To: comp.sys.att
Distribution: na
Organization: Chinet - Public Access Unix
Lines: 39

In article <1792@cadillac.CAD.MCC.COM> ned%cad@MCC.COM (CME Ned Nowotny) writes:
>In article <14463@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes:
>>My thanks to all who have responded via mail or news posting to my
>>question about forcing the Korn shell (KSH) to run a script using the
>>Bourne shell (SH) instead of itself.  There have been no completely
>>satisfactory answers, but I will summarize the State Of What Is Known.

Well, let me take a shot: put the following line as the first of any script
you want to run only under ksh, not sh:

2>/dev/null PPID=0 && { echo "$0: korn shell script" 1>&2; exit 1; }

It's awful to look at, but it works.  It's worse to type, and I haven't
figured out any way to put it in a variable or alias or function or
anything.

The rational is this:  using any of the built-in commands which are in ksh
but not sh to detect the difference can never be bulletproof, because a
binary (or whatever) can always be created with the same name as the ksh
built-in, which will do something (who knows what) under sh.  In fact, it
is not a particularly remote possibility that this could happen, because
writing binaries to emulate ksh built-ins is a perfectly reasonable thing
to do.

In fact, there is nothing that ksh can do that sh can't which can be
a bulletproof test, because ksh is supposed to be a superset of sh, and
even though it isn't it is legitimate for future versions to be closer to
being a superset--therefore any failures of super-setness used to make a
test are liable to go away.

What is needed is something which sh can do that ksh can't.  So far as I
can tell by empiric methods there is only one such thing--assign to the
PPID environment variable.  (ksh can assign to RANDOM, PWD and all the
others I tested.)  I think it is reasonable to assume that as long as ksh
implements the PPID envar, it cannot afford to permit it to be changed
(since it cannot change its parent.)  In fact, "typeset -r" reveals that
PPID is the only built-in envar with the R/O attribute.

I will be delighted if someone can improve on this miserable kludge.