Response file as an alternative to command line passing of arguments/commands/options?

[Matt Mackall]

On Thu, 2010-12-23 at 12:20 -0600, Steve Borho wrote:
> 2010/12/23 Lasse Vågsæther Karlsen <lasse at vkarlsen.no>:
> > The reason I'm asking the following question is that I'm writing a .NET
> > class library that wraps around the Mercurial command line client, and
> > ".NET-ifies" the interface, eventually building a command line and executing
> > it, capturing and parsing the output from the client back into .NET.
> > Then I found this question on Stack
> > Overflow: http://stackoverflow.com/questions/4512321/resulting-command-line-for-hg-exe-too-long-error-in-mercurial,
> > indicating that a program generated a too long command line for Mercurial,
> > the shell, or whatever, to process.
> > Then it dawned on me that the problem described in that question might be a
> > problem for my library as well, although I don't know how big that would be.
> > I will test to get the exact limits.
> > However, at this point I thought that perhaps the Mercurial command client
> > has a way for me to put all the arguments to it into a text file, and just
> > ask it to read from that in addition to whatever is on the command line,
> > however digging into the help file doesn't seem to give me any way to do
> > that.
> > Asking on irc (#Mercurial @ freenode) seems to indicate that this issue has
> > been asked on the mailing list before, and discard, so I have a couple of
> > questions:
> > 1. Is there such a way?
> > 2. If not, wouldn't it be a good idea, seeing as the command line
> > is advertised as the stable public API
> > (ref: http://mercurial.selenic.com/wiki/MercurialApi), if you read the
> > question linked to above, the way to get around it was to commit in batches,
> > surely that can't be the right way to do it?
> > 3. What alternatives do I have? Pull up my sleeves and submit a patch?
> > (though that would be aways before coming seeing as though I know Python, I
> > am not an expert and I don't know the Mercurial code)
> > In lieu of question #3, I was thinking that perhaps my class library could
> > write out Python files instead, calling directly into the Mercurial code,
> > but this would mean that I would require both Python installed and more than
> > the pure binary (I'm guessing at this) to be able to actually call into the
> > code from a python program.
> > I also asked my own question about this on Stack Overflow, but going by the
> > answers on irc, I don't think there is a way to do
> > this: http://stackoverflow.com/questions/4517628/mercurial-command-line-client-reading-commands-options-and-arguments-from-a-fi
> 
> Do you have links to the previous mailing list discussions?  I'm
> curious why it has been rejected in the past.  I suspect this would be
> a fairly simple patch, and would not break any existing APIs.
> 
> To make life simpler, it should support a null ('\0') delimited file format.

As this is generally a matter of filenames, it'd be quite easy to extend
the 'pattern' matching in match.py to do this generically for all
commands. See the beginning of mercurial/match.py for what patterns we
currently support. The ideal place to insert this is probably
_normalize: it can detect things of the form "file:foo.lst" (or
whatever) and recurse.

-- 
Mathematics is the supreme nostalgia of our time.