GNU bug report logs - #6784
24.0.50; cmdproxy incosistency with command pathnames

Previous Next

Packages: emacs, w32;

Reported by: Óscar Fuentes <ofv <at> wanadoo.es>

Date: Tue, 3 Aug 2010 15:57:01 UTC

Severity: normal

Found in version 24.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 6784 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Laimonas Vėbra <laimonas.vebra <at> gmail.com>
Cc: ofv <at> wanadoo.es, 6784 <at> debbugs.gnu.org
Subject: Re: bug#6784: 24.0.50; cmdproxy incosistency with command pathnames
Date: Tue, 03 Aug 2010 22:28:22 +0300
> From: Laimonas Vėbra <laimonas.vebra <at> gmail.com>
> Cc: 6784 <at> debbugs.gnu.org
> 
> Óscar Fuentes wrote:
> 
> > That's one more incosistency: a long command works fine, then you put
> > that command as part of a pipe chain and it stops working. I guess the
> > current cmdproxy approach is the lesser evil.
> 
> It's a CreateProcess() (in cmdproxy.c) _valid_ path requirement/problem; 
> valid path/directory separator is (should be) '\':

But the name of the shell, which is the only file name CreateProcess
should care about in this case, _is_ converted to use backslashes:

      progname = getenv ("COMSPEC");
      if (!progname)
	fail ("error: COMSPEC is not set\n");

      canon_filename (progname);

And canon_filename is

    char *
    canon_filename (char *fname)
    {
      char *p = fname;

      while (*p)
	{
	  if (*p == '/')
	    *p = '\\';
	  p++;
	}

      return fname;
    }





This bug report was last modified 14 years and 198 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.