Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!CZHRZU1A.BITNET!K538915
From: K538915@CZHRZU1A.BITNET.UUCP
Newsgroups: comp.sys.atari.st
Subject: Re: ...GEMBOOT... (really usage of shell_p)
Message-ID: <8704272221.AA01484@ucbvax.Berkeley.EDU>
Date: Mon, 27-Apr-87 09:20:27 EDT
Article-I.D.: ucbvax.8704272221.AA01484
Posted: Mon Apr 27 09:20:27 1987
Date-Received: Wed, 29-Apr-87 01:07:35 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 22

Jos Vermaseren
t68@nikhefh.uucp
writes:
>It is alarming to see that some people use the currently empty system
>variables for different purposes than they have been intended too.
>If GEMBOOT uses the variable _shell_p for its own purposes this is
>going to upset the programs that use it properly.
>This variable is intended for shell programs that submit child processes.
>The shell program can put here the address of one of its subroutines.
>The child process sees then that there is a shell and can have the already
>resident shell execute commands. .......................................
Sorry Joe, but you are dreadfully wrong! As experiment shows shell_p is a
pointer to a string (C-type) which contains the current search path. shell_p
is used by a number of AES functions including rsrc_load. Any other usage
of shell_p will probably crash a number of programs. Where did you get
your info from?


                         Simon
                         K538915@CZHRZU1A.BITNET

PS: It would be nice to have a system variable that does what you describe!