Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!b.gp.cs.cmu.edu!Ralf.Brown@B.GP.CS.CMU.EDU
From: Ralf.Brown@B.GP.CS.CMU.EDU
Newsgroups: comp.os.msdos.programmer
Subject: Re: Long command lines
Message-ID: <26fb525a@ralf>
Date: 22 Sep 90 12:00:26 GMT
Sender: ralf@b.gp.cs.cmu.edu
Organization: Carnegie Mellon University School of Computer Science
Lines: 27
In-Reply-To: <2728@dataio.Data-IO.COM>

In article <2728@dataio.Data-IO.COM>, bright@Data-IO.COM (Walter Bright) wrote:
}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.

What if you want to use an actual response file that just happens to
have the same name as an environment variable needed for some other
program?

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

Minor nit: the environment may only be 32K long, so the practical limit on
command lines will be around 31K due to other environment strings.

--
UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask
ARPA: ralf@cs.cmu.edu  BIT: ralf%cs.cmu.edu@CMUCCVMA  FIDO: 1:129/3.1
Disclaimer?    |   I was gratified to be able to answer promptly, and I did.
What's that?   |   I said I didn't know.  --Mark Twain