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

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

[Richard Stallman]

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?


Date: Tue, 25 Mar 2003 11:11:59 -0600
From: Eric Pement <eric.pement@moody.edu>
To: bug-gnu-emacs@gnu.org
Subject: ediff merge fails on Win2K - RESOLVED!
Sender: bug-gnu-emacs-bounces+rms=gnu.org@gnu.org

This bug report will be sent to the Free Software Foundation [ ... ] 
Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

  Several minutes ago, I sent in a bug report about ediff-merge-files
  failing on a Win2K machine using GNU Emacs 21.2.1. Specifically,
  Emacs complained that "diff3.exe" could not be executed, even though
  "diff3" was the proper version, was on the Windows PATH, and even
  though ediff-compare-files had worked successfully in the past.

  As I looked at the error message which I had to paste in with
  continuation lines because it would have been unreadably long, it
  occurred to me that perhaps this long line was the cause of the
  problem. In Windows 2000, the default environment setting for the
  TEMP variable is "%USERPROFILE%\Local Settings\Temp". Of course, the
  %USERPROFILE% is expanded to "C:\Documents and Settings\username",
  and three copies of this string (plus 3 different filenames) are
  appended to the diff3 command, thus creating a very long line.

  Here's how I resolved it:

  I manually created C:\TEMP (which is not in Windows 2K by default).
  I altered the TEMP variable to point to C:\TEMP. That's all I did;
  now everything works.

  My recommendation: I recommend that the ediff fuction calculate the
  length of the command line which will be sent to CMD.EXE, before the
  command is actually sent. If the length of the command line is
  greater than CMD.EXE allows, issue an error message suggesting that
  the user reduce the length of the TEMP environment variable. Thanks
  for listening.

--
Eric Pement - pemente[at]northpark.edu, eric.pement[at]moody.edu

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

[Eli Zaretskii]

> 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.

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

[Richard Stallman]

    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.

Is this the case?

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

[Eli Zaretskii]

> Date: Tue, 01 Apr 2003 08:58:57 -0600
> From: Eric Pement <eric.pement@moody.edu>
> >
> >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.
> 
>    Hello!  I'm the original poster. IIRC, I got the version of diff3 from
> from simtel.net, in the gnuish section.

This confirms my suspicion: gnuish programs are DOS executables.

So I suggest to find and install a native Windows port of Diffutils
(yes, MinGW or Cygwin).