Re: [eric.pement@moody.edu: ediff merge fails on Win2K - RESOLVED!]

["Eli Zaretskii" <eliz@elta.co.il>]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 27 Mar 2003 14:04:55 -0500
> 
> Kifer thinks that call-process is the right place to fix this,
> and that seems like a plausible idea.  Does anyone who works
> on DOS or Windows want to fix this?

I'm not sure Eric's diagnosis, namely, that the long file names
overflow the Windows shell's command-line length limit, is correct.
Only the DOS shell has a ridiculously short (126-character) limit on
command lines; all the other MS shells have much more resonable limits
of several KBytes at least.  I think 32KB is the most ``popular''
limit.

I suspect that the OP had a DOS port of Diffutils installed, and thus
Windows invoked them thru the DOS shell COMMAND.COM, which indeed has
that 126-char limit.  If that's true, the solution is to install a
native Windows port of Diffutils.

In any case, Eric's suggestion at solving the problem is problematic,
as IIRC it is next to impossible to find out what is the actual
limitation on the command-line length on a given Windows system.  For
starters, it depends not only on the shell but also on the program
being invoked (different compilers impose different limitations due to
their startup code that processes the command line into argv[]).  All
we could do is use some approximation which could lose in some cases.

It could also be that it's not the command-line's length that poses
the problem, but the fact that the file names have embedded blanks.
Perhaps those blanks are not handled like Windows shells expect (e.g.,
perhaps Emacs uses a Unix-style escaping of the blanks).

If my guesses are wrong, someone, preferably Eric himself, should
investigate this problem a bit more, since I cannot see how else could
such a problem happen.