🚀 go-pugleaf

In article <7192@hydra.Helsinki.FI>, kankkune@cs.Helsinki.FI (Risto Kankkunen) writes:
> In article <26da5df5@ralf> Ralf.Brown@B.GP.CS.CMU.EDU writes:
>>In article <FooBarataio.Data-IO.COM>, bright@dataio.UUCP wrote:
>>}[passing long command lines in an env var]
>>}What name do they use for the environment variable? Is there any sort
>>}of defacto standard for this? ...If there is no commonly used environment 
>>}variable, how about defining one, I propose "CMDLINE".

There can be a problem using the environment to store long command lines with
conventional DOS: the environment space is small by default, and if you
increase it in config.sys you have to choose a number large enough for any long
command line you might need in the future, and this wastes space each time a
program is nested. 

>>}What if both the environment variable
>>}and a command line exist, does the environment variable come 'before'
>>}or 'after' the command line?
My software generally uses the conventions:
(a) if there is an environment variable with the same name as the program, it
inserts that string *before* the given command line in the PSP, assuming it
contains options (which traditionally go before other parameters, but in fact I
allow them anywhere).
(b) if the command line (or, for that matter, the envirnoment string mentioned
in (a) above), contains " @" followed by a filename, the contents of that
filename are inserted in the command line (where the "@" and filename was).
Althought this potentially allows for *very* long command lines (I'm used to DG
RDOS & B.Basic with kilobytes worth of command parameters!), all my programs at
the moment are limited to a total of 255 bytes, still, it's an easy way to get
around the fact that people may use the software from any version of DOS (2+)
and any environment allocation, and any command interpreter.
(c) I'm happy to look for an environment variable called CMDLINE; I suggest its
contents should go *after* whatever is in the command line already.
>
> An environment variable is simple to use, but I think it would be
> cleaner to place the command line arguments after all the variables and
> the terminating double null in C/Unix-fashion. After all, there is
> already the program name (=argv[0]) there and the word preceeding it
> contains 1, so it seems to be argc...
(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. From DOS 2 onwards, it is possible
for each program called to get the environment space it actually needs, but so
far the memory allocation systems seems a bit poor, to say the least.

>>The 4DOS COMMAND.COM replacement uses CMDLINE to store the full command line..
I haven't played much with 4DOS, but this underlines up the question of what we
(the programming community, I guess), could do to set standards for command
interpreters. I suggest that, in addition to programs using (a) to (c) above,
and checking for a command interpreter doing (d), we define a few extra
punctuation features for command interpreters while we're at it, so everyone
can plan for them. So I suggest that command interpreters...

(e) expand any [@filename] to include the contents of the file in the command.
Notice the [ and ] around it; it would pass any plain "@" unchanged, for
compatibility with anything that presently wants a "@" in the command line.
Possibly %@filename% would be more consistent, but I prefer to see [ and ]
because it is easier to spot mistakes than with %, and is better for nesting,
and is similar to DG's AOS operating system - not that I'm going out of my way
to copy others, but if someone's got a standard already, why invent a new one?

(f) expand any [@filename number] to include the given line number from the
given file, as above.

(g) expand any [!command] by executing the command after the [! and placing
whatever it writes to the standard output into the new command line's text.
This is pretty much compatible with DG AOS/VS.

(h) expand [?prompt] by asking the user for input.

(i) define a "command continuation" character, e.g. ",", so command lines can
carry on over one line of text, as per decent operating systems.

(j) improve the piping facilities a little, e.g. a tee facility and perhaps a
special highly-buffered device driver for temporary files, and ">>", etc.

> Does anyone know if DOS 5.0 will set any standards in this area?
I don't know about MSDOS 5, but DRDOS 5 allows @filename in most of its own
utilities, (in the same way that my utilities do, it seems). It also allows /h
for help (I would have liked /?, but at least it's something).

Mark Aitchison, Physics, University of Canterbury, New Zealand.