From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Eli Zaretskii" Newsgroups: gmane.emacs.bugs Subject: Re: possible bug in process.c? Date: Thu, 15 Jan 2004 10:30:39 +0200 Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Message-ID: <5567-Thu15Jan2004103039+0200-eliz@elta.co.il> References: <20040114185244.GA17851@mlvezie.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1074155892 14457 80.91.224.253 (15 Jan 2004 08:38:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 15 Jan 2004 08:38:12 +0000 (UTC) Cc: bug-gnu-emacs@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jan 15 09:38:08 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ah30y-00085L-00 for ; Thu, 15 Jan 2004 09:38:08 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Ah301-0002Wk-1F for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 Jan 2004 03:37:09 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1Ah2zw-0002WA-8d for bug-gnu-emacs@gnu.org; Thu, 15 Jan 2004 03:37:04 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Ah2zP-0002Os-0H for bug-gnu-emacs@gnu.org; Thu, 15 Jan 2004 03:37:03 -0500 Original-Received: from [199.232.41.8] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.24) id 1Ah2zO-0002Oj-NF for bug-gnu-emacs@gnu.org; Thu, 15 Jan 2004 03:36:30 -0500 Original-Received: from [192.114.186.18] (helo=bilbo.inter.net.il) by mx20.gnu.org with esmtp (Exim 4.24) id 1Ah2xh-0005yq-8m for bug-gnu-emacs@gnu.org; Thu, 15 Jan 2004 03:34:45 -0500 Original-Received: from zaretski (pns03-196-191.inter.net.il [80.230.196.191]) by bilbo.inter.net.il (Mirapoint Messaging Server MOS 3.3.8-GR) with ESMTP id CFM48054; Thu, 15 Jan 2004 10:34:21 +0200 (IST) Original-To: Michael Vezie X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9 In-reply-to: <20040114185244.GA17851@mlvezie.org> (message from Michael Vezie on Wed, 14 Jan 2004 13:52:44 -0500) X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Bug reports for GNU Emacs, the Swiss army knife of text editors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.bugs:6567 X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:6567 > Date: Wed, 14 Jan 2004 13:52:44 -0500 > From: Michael Vezie > > /* If program file name is not absolute, search our path for it */ > if (!IS_DIRECTORY_SEP (XSTRING (program)->data[0]) > && !(XSTRING (program)->size > 1 > && IS_DEVICE_SEP (XSTRING (program)->data[1]))) > { > > ... at which point it then processes a relative pathname file (looking through Vexec_path > for the executable, etc). > > Maybe I'm reading this wrong (help me out if I am), but shouldn't that last line there read: > && !IS_DEVICE_SEP (XSTRING (program)->data[1]))) > note ^ > > Here's how I read it: > > If the first character is not a directory separator ('/' or '\\') and the string is longer than > 1 and the second character is a device separator (':')... you're checking here if the string denotes > a relative path. But if the second character is a ':', then it's something like: > > c:/fsf/emacs-21.3/bin/cmdproxy.exe > > which is an absolute path, and doesn't require looking through Vexec_path. My reading of that code is: If the first character is not '/' or '\\' and either the file name is not longer than 1 character or its second character is not ':', then it's not an absolute file name. > In any case, I get an error preceeded by "Searching for program" when I set my SHELL environment > variable to c:/fsf/emacs-21.3/bin/cmdproxy.exe (it should never search for the program in the path > with an absolute path like that), and things work fine when I set my SHELL environment variable to > simply cmdproxy.exe Could you please see with a debugger whether the code in question is indeed the one that's misbehaving?