🚀 go-pugleaf

In article <1042@viper.Lynx.MN.ORG>, john@viper.Lynx.MN.ORG (John Stanley) writes:
> In article <2124@cwruecmp.UUCP> pm@cwruecmp.UUCP (Prabhaker Mateti) writes:
>  >I would like to suggest the following usage for _shell_p.
>  >
>  >------------------------------------------------------------------
>  >[description of method]
>  >--------------------------------------------------------------------
> 
>   The easiest method to identify the shell that won't effect any 
> programs in a negative way would be to define a command that could 
> be passed to the shell.  The shell would then pass back either an 
> error code, nothing, or (if it's a shell that supports this) a 
> pointer to an identification block similar to the one you mentioned
> in your idea.
> 

This is all getting us in trouble. The easiest way to identify a parent
process is via the environment string. So if you want to make shure that
you are running from a particular shell you check in the environment for
the string SHELL=whatever. Any decent shell program passes its identity
this way.
For the communication between an editor and a shell one doesn't even need this,
as the shell will eat the command or it won't, depending on whether the user
knows the syntax of the shell he is using. For utilities that come with a shell
there is also no need for an identity check, as they were designed for the
shell in case. Only if you want to make them more general you have to look
in the environment.

The best way is still the way as cooked up between Atari and Gert Poletiek.
To get around the problem of GemDos not zeroing some variables one could
have a little program as the first program in the auto folder that erases
the contents of the _shell_p variable. In that case everything works
perfectly and there is no need to change the 'current standard'.

Jos Vermaseren
T68@nikhefh.uucp