Path: utzoo!dptcdc!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!unisoft!bdt!david From: david@bdt.UUCP (David Beckemeyer) Newsgroups: comp.sys.atari.st Subject: Re: Extended argument passing conventions in Pexec() [MWC] Keywords: MWC Pexec Argument Passing Message-ID: <546@bdt.UUCP> Date: 17 Apr 89 18:33:14 GMT References: <841@per2.UUCP> <1453@atari.UUCP> Reply-To: david@bdt.UUCP (David Beckemeyer) Organization: Beckemeyer Development Tools, Oakland, CA Lines: 93 In article <1453@atari.UUCP> kbad@atari.UUCP (Ken Badertscher) writes: [ about the MWC ARGV method ] >It is simple, yes, and it simply won't work. Using ARGV, a parent >is required to copy its environment before it execs a child. What if >someone decides they'd like to sort the environment variables for the >child as they create the child's environment? What if they want to >filter it? The environment comparison fails, and validation goes out >the window. The MWC tools already* provide a flag ("unreasonable" >command line length byte) which can be used to validate the ARGV, and it >is unused by the MWC startup code! > Ken, it sure looks like you want to attack MWC here. If the method is "standard", "good" programs won't mess with the environment in "bad" ways. I think something that Allan Pratt (sp?) suggestted a long time ago where the parent places a variable like "PARENT=" or simething which contains the parents basepage address is a reasonable additional method of validation of the ARGV environment. Also the MWC startup could be modified to use the "unreasonable" command line length byte and Roger's suggestion of nulling out the env. at the ARGV is also good. >| ----------------------------------------------------------------------- >| Programs which ignore the ARGV convention for arguments end up >| mis-interpreting ARGV specified arguments as environmental variables >| and passing screwed up environments on to their children. >| >| This problem is addressed differently by the ARGS and xArgs proposals. >| >[ means of addressing the problem omitted ] > >Hah, I caught you! You admit that ARGV is imperfect! ;-) You are even >willing to change the startup code to make it more perfect! I think that's *exactly* what Roger was saying. What's wrong with that? Are you suggesting the xArgs and/or your method are perfect? They all have problems. I think any method using the environment for something other than it is intended for is never going to be perfect. Sorry. GEMDOS should just do it right. That's the only "perfect" answer. I think what Roger is saying is that with some minor improvements the ARGV method is OK. > >| [ Roger discusses solutions for programs which mess up the env. ] >That's very nice, but the other two methods of extended argument passing >don't require ANYBODY to be insulated from them. In fact, all THREE >methods can peacefully coexist in one system, except that ARGV will >cause problems for programs which haven't been "innoculated" against it. Say what? Are you saying that I won't have to upgrade any of my 500 or so utilities? None of my 25,000 customers will need upgrades with the new Atari standard? Not including the countless non-commercial home-grown utilites that use MWC ARGV arguments? You see all approaches are going to require lot's of binary patch programs and upgrades. Whether it's for "innoculation" or "fixes" I don't really see the difference and neither will the users. I think you're forgeting how many *commercial* programs use the ARGV "standard". This will play a big role in the standardization phase. > >| If Atari wants MWC to discard the ARGV argument convention, I hope >| they'll wait until they can find something better to replace it with. :-) >| >| -- rec -- > >If MWC wants Atari to adopt the ARGV argument convention, I hope they'll >come up with some better defenses for it. >;-) This is the most important and strongest statement that Roger makes and you simply discount it. I don't think that either your method or xArgs are really better than ARGV in all respects; they're just different. Each method has advantages and disadvantages. What I'm is saying WHY CHANGE IT JUST TO CHANGE IT? Wait it out; let's get this thing fixed right instead of just introducing a bunch of new problems for developers and end-users alike. Do we have a solution looking for a problem or what? :-) > >-- > Ken Badertscher | #include > Atari R&D | No pith, just a path: > Software Engine | {portal,ames,imagen}!atari!kbad -- David Beckemeyer (david@bdt.UUCP) | "Adios amigos. And, as they say when Beckemeyer Development Tools | the boys are scratching the bad ones, 478 Santa Clara Ave. Oakland, CA 94610 | 'Stay a long time, Cowboy!'" UUCP: {uunet,ucbvax}!unisoft!bdt!david | - Jo Mora