🚀 go-pugleaf

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. I feel it is easier for "other" command interpreters (like 4DOS) to
lead the way, rather than to campaign for Microsoft to change (they seem to add
stuff only a long time after it has been available elsewhere).

In the mean time, people probably want to write programs that can receive long
command lines, and I suspect the answer for the moment is:

(a) if an environment variable called "CMDLINE" has been defined, then use that
(after anything in the PSP, perhaps), else
(b) if the number of parameters after the normal environment variables is
greater than 1 (and the version of the o/s is 3 or later), then get the
parameters from there instead of the command tail in the PSP, and
(c) if the particular program has some extra convention for getting more
information from the environment, stuff that in now (e.g. my LOCATE program
looks at the environment variable "LOCATE" for such things as the default list
of directories to search), and lastly
(d) if any parameters start with an "@", and your program has no special reason
for accepting parameters starting with an "@", expand the filename following
the "@" (if possible) by including the contents of that file in the command
line at that point.

> 4DOS also has >&, >>&, >!, >>!, >&!, and >>&!.  It isn't DOS that limits
> the redirection capabilities, it's COMMAND.COM....
Yep, COMMAND.COM is pretty pathetic really, and it is what many people judge
DOS by; DR's version is a bit better, and 4DOS significantly better still. Even
with gooey windows and possibly voice-input user interfaces, there is, and will
remain, the need for improved communication between user and command interface,
as well as command interface and  application programs. If Microsoft themselves
aren't leading a push for improvements, can enough people band together to
establish standards? (I hope so, but I'm open to comments).

Mark Aitchison, U of Canty, N.Z.