Xref: utzoo comp.unix.questions:15049 comp.sys.att:7027 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bionet!ames!vsi1!wyse!wyse.wyse.com!bob From: bob@wyse.wyse.com Newsgroups: comp.unix.questions,comp.sys.att Subject: Re: Forcing /bin/sh in a script under V/386 3.2 Korn shell Message-ID: <2318@wyse.wyse.com> Date: 20 Jul 89 00:27:16 GMT Sender: news@wyse.wyse.com Reply-To: bob@wyse.wyse.com () Followup-To: comp.unix.questions Organization: Wyse Technology Lines: 71 In Article 14223 of comp.unix.questions ned@mcc.com (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. < > < ... Lines Deleted ... < There is some missing history here. < < In the old days (around Version 6 or 7 and before), the Bourne shell < did not have a comment character, but it did have the null command, ":". < Now, the null command was useful in several ways ... ----lines also deleted---- My apologies as I did not see the original summary that Tom Neff put out, which may have already included the solution I am sending for getting ksh to exec sh. Also, this is my first posting, so if I have neglected some portion of netiquette, please let me know via e-mail :-). I have also supplied some additional stuff about uses of the colon command. As noted, using the colon command for comments is a problem because of the possible side effects. I came across the recommendation, in _Introducing the UNIX System_ by McGilton and Morgan, that it is best to place single quotes around the arguments to prevent these side effects. The colon command is also useful for evaluation of variables, as in the following: : ${CWDIR=`pwd`} which will set CWDIR to the current directory if CWDIR is not already set. If the colon command were not used the shell would then substitute this name and attempt to execute it as a commend. With respect to the original question of Tom Neff's, perhaps the following would help. It depends on the fact that both _sh_ and _ksh_ will execute the similar code, while _ksh_ adds some "extras", such as RANDOM, which _sh_ will treat differently. In _ksh_ each reference to RANDOM will cause the value of RANDOM to change. if [ "$RANDOM" -eq "$RANDOM" ] then # what you want sh to do else # exec sh on this script exec /bin/sh `whence $0` "$@" fi The _whence_ builtin generates the full pathname of the current file (assuming it is in the path) and _sh_ is used to run it. The original arguments must also be supplied to this new invocation. Using the quoted $@ above (if I understand it correctly), will guarantee that the form of the arguments on the original command line will be passed to the new script invocation in exactly the same form. I picked up the general idea from some _ksh_ examples I saw once, in _The Wizards Grabbag_ in UNIXWorld, but I am afraid I do not remember the author, nor do I have the original at hand. I have used the method and found that it works as advertised. (The original was used to guarantee that _ksh_ was run on the script, which contained _ksh_ specific code.) Hope this proves useful :-) Bob McGowan Wyse Technology, San Jose, CA ..!uunet!wyse!bob bob@wyse.com