🚀 go-pugleaf

In article <1990Sep21.104931.9205@canterbury.ac.nz> phys169@canterbury.ac.nz writes:
}In article <10522@pt.cs.cmu.edu>, ralf@b.gp.cs.cmu.edu (Ralf Brown) writes:
}> In article <1990Sep20.102811.9190@canterbury.ac.nz> phys169@canterbury.ac.nz writes:
}> }(d) I'd like to see such a method become a standard, but this would really
}> }need replacing COMMAND.COM. The idea of placing them after the program name in
}> }the environemt would be good, so long as enough people (and alternative command
}> }interpreters) get together and agree on it. 
}> 
}>Actually, the place it would need to be implemented is in the EXEC DOS call,
}>since that is what builds the environment copy and adds the program name.
}
}But a command processor could set up the environment with the parameters there,
}without waiting for a new DOS, or requiring users to upgrade their whole o/s.
}True, it would be nicer to get the DOS call to some of the work, but I'm still
}correct in saying that it is really essential for the command interpreters to
}do their bit.

Sorry, that won't work, since anything after the environment (such as extra
parameters) is *NOT* copied when making a copy of the environment for the
EXECed program.  That's why the DOS call has to add the extra parameters as
it now adds the program name, if you want to pass a long commandline after
the program name.
-- 
{backbone}!cs.cmu.edu!ralf  ARPA: RALF@CS.CMU.EDU   FIDO: Ralf Brown 1:129/3.1
BITnet: RALF%CS.CMU.EDU@CMUCCVMA   AT&Tnet: (412)268-3053 (school)   FAX: ask
DISCLAIMER?  Did  | Everything is funny as long as it is happening to
I claim something?| someone else.  --Will Rogers