Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!pilchuck!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Long command lines
Message-ID: <2728@dataio.Data-IO.COM>
Date: 21 Sep 90 20:39:42 GMT
References: <1990Sep20.102811.9190@canterbury.ac.nz> <10522@pt.cs.cmu.edu> <1990Sep21.104931.9205@canterbury.ac.nz>
Organization: Data I/O Corporation; Redmond, WA
Lines: 49

In article <1990Sep21.104931.9205@canterbury.ac.nz> phys169@canterbury.ac.nz writes:
<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:
<(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.

After going around and around on this, I came up with what I feel is a
fine solution:

A parameter starting with @ is taken to be a 'response file'. The response
file is read in and inserted into the command line replacing the @filename
parameter. So far, this is pretty standard. I extended the concept so that
filename was first searched for in the environment, and then looked for
on the disk. This avoids the inefficiency of writing and reading files
when spawning a program. There is no need to reserve a special environment
variable name.

putenv() is used to set the environment variable, so there is no problem,
the command line can be up to 64k (!) long.

I have implemented this in all of Zortech's utilities, including MAKE, and
it appears to neatly solve this problem. Especially with MAKE, now the
command lines can be arbitrarilly long. MAKE 'knows' that Zortech programs
can handle this. MAKE can be informed about other programs that can handle
passing the command line in the environment by a special flag on the rule
line (a '*').

This improvement will appear in the Zortech's next release.

I propose this be a standard because:
1. It is a rather trivial extension to the @filename response file concept.
2. It works with all versions of DOS and OS/2.
3. No special environment variable name needs to be reserved.
4. No cleverness with undocumented environment manipulations is necessary.
5. No decision about the positioning of the long command line relative
   to the PSP command line is necessary.
6. Since most compilers support using putenv() in conjunction with spawn(),
   there shouldn't be any problem supporting this.
7. One problem with response files is avoiding file name collisions when
   using a network or multitasking software. This problem doesn't exist with
   the environment variable approach, because each task has its own copy
   of the environment.
8. It's much faster than reading and writing disk files.

The only fault with this scheme is that it doesn't enable you to type in
a long command line at the DOS prompt. I think Microsoft will have to fix
that one.