Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!mit-eddie!ll-xn!ames!oliveb!pyramid!hplabs!ucbvax!CZHRZU1A.BITNET!K538915
From: K538915@CZHRZU1A.BITNET
Newsgroups: comp.sys.atari.st
Subject: RE: ......._shell_p......
Message-ID: <8705151418.AA22859@ucbvax.Berkeley.EDU>
Date: Thu, 14-May-87 20:47:15 EDT
Article-I.D.: ucbvax.8705151418.AA22859
Posted: Thu May 14 20:47:15 1987
Date-Received: Sun, 17-May-87 00:11:15 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 30


Mike Fisher (fisher@yale.arpa) writes
>Allan Pratt reports:
>> I have investigated the alleged use of _shell_p by the AES and
>> the Mark Williams shell, and I can't see that either of them uses this
>> variable.
>
>It's not surprising that none of these programs access location
>0x4f6.  However, they obviously do use the string that is pointed
>to by that location.  There are probably other pointers to it floating
.................................
>code for Pexec.  Perhaps the DESKTOP passes the value of _shell_p
>to Pexec when you double click on a .PRG file.  Or perhaps the desktop
...................

I'm pretty sure that the DESKTOP PExec's with the string pointed to by
_shell_p used to make a enviroment string of the form PATH=A:\;......
rsrc_load and shel_find probably use the shel_envrn call to get a
pointer to the string following PATH= in the basepage.
  To try this out, use something like the shell for OSS PERSONAL PASCAL
which doesn't try to maintain its own PATH. An example: I've got PATH
set to C:\;D:\;E:\;F:\;D:\UTILITIE.S\; this enables me to execute a program
in D:\UTILITIE.S\ from the Pascal shell and it will still find the resource
file in D:\UTILITIE.S\.

                            Simon Poole
                            K538915@CZHRZU1A.BITNET

PS: Allan, I'm Simon not "Simon" (or are you "Allan"?)
PPS: Mike, how does it come that we are consulting Atari on their own OS?