Path: utzoo!attcan!uunet!husc6!mailrus!cornell!uw-beaver!ubc-cs!alberta!oha!tony
From: tony@oha.UUCP (Tony Olekshy)
Newsgroups: comp.unix.wizards
Subject: How to use $SHELL (was Re: make importing SHELL)
Message-ID: <253@oha.UUCP>
Date: 7 Oct 88 11:13:27 GMT
References: <8616@smoke.ARPA> <452@alice.marlow.uucp> <67870@sun.uucp> <67925@sun.uucp> <128@cetia.UUCP> <13753@mimsy.UUCP> <4147@bsu-cs.UUCP>
Organization: Olekshy Hoover & Associates Ltd., Edmonton,Alberta,Canada
Lines: 29

In <8616@smoke.ARPA>, Doug Gwyn (gwyn@brl.arpa) writes:
> 
> So far as I know, no shell uses the SHELL environment variable
> to determine what shell to use when "exec"ing a shell script.
> 
> SHELL is used when setting up a new layer or window, etc.

Yup.
$SHELL belongs to the applications.
In my applications, I use the following sub-shell dispatching process:

 1) If the command comes from the application internals, I run the application's
    shell with the -c option.  Both the "-c" and the command are separate
    arguments to exec*, so quoting is not a problem.  The application's shell
    is #defined to the application.

 2) If the command comes from the user's response to the "I want to run a
    command" (soft)key, and the user elected the "start an interactive shell"
    suboption, I start the $SHELL program directly.

 3) If the command comes from the user as in (2), but the user actually entered
    a command to be run in response to the prompt presented when the softkey
    was selected, then I run $SHELL passing "-c" and the command as in (1).

 4) If the user does not have a $SHELL for getenv(), then I either provide
    the application's #defined shell, or sh, or an error messase, depending
    on the users.

Yours, etc., Tony Olekshy (...!alberta!oha!tony or tony@oha.UUCP)