Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!bfmny0!tneff
From: tneff@bfmny0.UUCP (Tom Neff)
Newsgroups: comp.sys.att
Subject: Re: Forcing /bin/sh in a script under V/386 3.2 Korn shell
Summary: isn't it?
Message-ID: <14463@bfmny0.UUCP>
Date: 13 Jul 89 01:37:47 GMT
References: <14445@bfmny0.UUCP> <1989Jul12.191342.1048@cs.dal.ca>
Reply-To: tneff@bfmny0.UUCP (Tom Neff)
Distribution: na
Organization: ^
Lines: 63

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.

 * There are a few minor incompatibilities between the way SH and KSH
   behave in a correctly written script, but the biggest reason why
   you would want SH to run a script instead of KSH (if it's simple
   and dumbed down to SH) is that KSH takes a lot longer to fork
   itself.  Thus tricks that let KSH, once forked, realize it should
   hand the reins over to SH (such as [ "$RANDOM" = "$RANDOM" ]) are
   not enough; you not only have to spend the time forking KSH but
   also the time to reinvoke SH.

 * There is an exact analogue to what I want for the C-Shell (CSH):
   if you put a colon ":" as the first line of a script, CSH will
   detect it and automatically spawn SH instead of itself to execute
   the script.  (This is the way AT&T documents it; some users claim
   that putting *anything* other than "#" at the start of the first
   line does it, or that a blank first line does it, but I recommend
   sticking with the AT&T convention to avoid blowing up on someone's
   weird CSH variant.)  You can see this done at the start of most of
   the AT&T supplied system shell scripts like installpkg and shutdown
   and even basename.  But no, it does not convince KSH.  To prove this,
   create the script

	:
	ps -f

 * If you must use one of the "tricks" like Todd Day's $RANDOM thing,
   for the sake of correct (though not faster) script execution, you
   should follow up with "exec" rather than sub-spawning SH underneath
   the KSH process.

	test "$RANDOM" = "$RANDOM" && exec /bin/sh -c $0 $*

   or to force KSH:

	test "$RANDOM" = "$RANDOM" || exec /bin/ksh -c $0 $*

 * Although you can't escape KSH's long fork time (apparently), you can
   definitely escape the potentially lengthy process of glomming your
   ENV environment script for every subshell, by using the ENV trick
   described in the KSH documentation:

	export Envfile=$HOME/.env
	export ENV='${Envfile[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}'

   This cryptic mass will run your environment script (presumably
   including your favorite functions and aliases etc., and in this 
   example named ".env" in your home directory) if and only if you 
   spawn an interactive shell, such as a naked "!" from rn(1) or vi(1).  
   If you spawn a command directed subshell, a la "ksh -c echo hi", 
   the environment script won't run and your subprocess will get going
   a whole lot faster.

If anyone has an answer to the original question, operators are still
standing by.  :-)  If no one does, and if Dave Korn (or the fellow who
famously sits right next to him) is listening, an auto-SH convention
in scripts would be a Nice Thing To Have next version of KSH.
-- 
"My God, Thiokol, when do you     \\	Tom Neff
want me to launch -- next April?"  \\	uunet!bfmny0!tneff