Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!ucbvax!tut.cis.ohio-state.edu!osu-cis!att!ihlpb!TSfR!root
From: root@TSfR.UUCP (usenet)
Newsgroups: comp.sys.atari.st
Subject: Re: GEMDOS Extended Argument Standard
Summary: Oh lord, _ANYTHING_ but the environment
Message-ID: <512@TSfR.UUCP>
Date: 29 Mar 89 03:30:20 GMT
References: <1405@atari.UUCP>
Reply-To: orc@pell.UUCP (David L. Parsons)
Followup-To: comp.sys.atari.st
Organization: This Space for Rent - Lisle, IL
Lines: 88
Expires:

In article <1405@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes:
>  - GEMDOS enhancements are coming that will require a robust means of
>	passing lots of information between parent and child processes

> [discussion on pascal strings & the command line tail]

>  The upshot of all this is that it is* possible for a process to know
>if the ARGV in its environment is meant for it and not left over from
>one of its MWC/Manx/MT-C Shell spawned ancestors.  If its command line
>length is something unreasonable, a program can take that as a clue...

  What if the program uses the length byte to figure out length of command
  line tail like so:

    for (length = *(tail)++; length-- > && ....

  ????

  It would be nice to be able to have the extended arguments code also
  be able to handle talking to processes that don't grok extended arguments
  and which don't clear sign-extension on the length byte (which is not
  an unreasonable thing to ignore, because the tail can't be >127 chars.)

>XARG also bothers me, because it
>means that a child has to muck with its parent's address space.

 No kidding.  But xargs was designed under the reluctant assumption that
 the OS would never change to accomodate it.  Dale & I initially suggested
 that we use some of the `reserved' fields in the basepage for
 argc/argv (after all, the basepage is for process information, and
 _real_ argc/argv are most certainly process information) but Allan
 Pratt strongly objected to that, so we had to hack the environment
 and do the relatively byzantine bit of `environment-pointer-to-
 magic-verify-record-to-arguments-we-hope.'

 But at least xArgs doesn't carry the argument list to all the descendants
 of the process, which is what the Mark Williams `standard' does.  Dale
 and I felt that hacking parents data-space was less objectionable that
 filling the environment with crud (my word) / extranous information (his
 words :-)

>  Currently, I'm leaning towards the ARGV method with the iovector
>yanked, a negative byte value for the command line length to flag it,
>and a different name for the environment variable.

 This is with the argument list in the environment, right?  The big
 problem with this is that you will get those strings propagated all
 over the universe, anyway, and if a process modifies the environment
 with putenv(), the ARGV= stuff will be scrambled around.

 Say, for example, that I call the teeny-shell from a program that uses
 MWC arguments;  Teeny-shell will get ARGV=<0>ARG0<0><ARG1<0>...<0><0>.
 which will parse to at least one valid environment variable - ARGV=ARG0.
 If any of the arguments I passed into the teeny-shell have `=' in them,
 they, too, will get converted into valid environment variables. (if I
 do `tsh -i PATH=g:,c:\bin,c:\games,. some-initial-command', for example.)

 And if this child (the one who doesn't grok the MWC `standard') does
 a putenv() or two, it will end up (most likely) putting new environment
 variables at the end of the arglist, after the corpse of the argument-list.

 The diddles to the length of the cmdline tail will prevent children from
 incorrectly reading the environment, but there will still be this
 collection of garbage left orphaned in the environment.  And if the teeny-
 shell calls another process that groks MWC args, which then forks off another
 process, well, then that orphan will see the first ARGV= value, which is
 now being treated as a valid environment variable, and get stuck with the
 fun prospect of trying to figure out if it is, indeed, the start of the
 argument list or if it's something else.

>  I am not formulating a standard on a Sunday afternoon, though.

 That's a relief :-)

 If you're planning to do enhancements to TOS for extended argument passing,
 perhaps it's time to consider the basepage & additional gemdos traps for
 extended argument pexecing?  I don't like corrupting the environment with
 argument stuff*, because of the transient nature of arguments.  When you
 start diddling with the environment, you end up with having to make both
 the caller and the callee grok the format, otherwise you start to see
 strange little artifacts pop up all over the place.  If you use one of those
 reserved fields, well, if the child doesn't know what the entended arguments
 are, they die right there, rather than being carried all over God's creation
 by its children.


   -david parsons
   -orc@pell.uucp