From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.devel Subject: Re: [eric.pement@moody.edu: ediff merge fails on Win2K - RESOLVED!] Date: Thu, 27 Mar 2003 22:10:12 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <1438-Thu27Mar2003221012+0200-eliz@elta.co.il> References: Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1048796358 977 80.91.224.249 (27 Mar 2003 20:19:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 27 Mar 2003 20:19:18 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Mar 27 21:19:16 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18ydqG-0000Fb-00 for ; Thu, 27 Mar 2003 21:19:16 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18ydsI-0002qX-00 for ; Thu, 27 Mar 2003 21:21:22 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18ydoE-0006O9-05 for emacs-devel@quimby.gnus.org; Thu, 27 Mar 2003 15:17:10 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18ydny-0006Kg-00 for emacs-devel@gnu.org; Thu, 27 Mar 2003 15:16:54 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18ydnu-0006Hd-00 for emacs-devel@gnu.org; Thu, 27 Mar 2003 15:16:53 -0500 Original-Received: from frigg.inter.net.il ([192.114.186.16]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18ydnu-0006Gz-00; Thu, 27 Mar 2003 15:16:50 -0500 Original-Received: from zaretsky ([80.230.234.142]) by frigg.inter.net.il (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CGH41359; Thu, 27 Mar 2003 22:16:41 +0200 (IST) Original-To: rms@gnu.org X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 In-reply-to: (message from Richard Stallman on Thu, 27 Mar 2003 14:04:55 -0500) Original-cc: Eric Pement X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:12672 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12672 > From: Richard Stallman > 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.