Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <3BD43CF4.2611ABC3@syntrex.com>
Date: Mon, 22 Oct 2001 17:36:20 +0200
From: Pavel Tsekov <ptsekov AT syntrex DOT com>
Organization: Syntrex Inc.
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: more info on execvp problem
References: <3BD3EA44 DOT FF96A58A AT syntrex DOT com> <20011022112817 DOT C7609 AT redhat DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Christopher Faylor wrote:
> 
> On Mon, Oct 22, 2001 at 11:43:32AM +0200, Pavel Tsekov wrote:
> >Ok, here is what I've found about the execvp problem I mentiond in an
> >earlier post:
> >
> >Assuming the simple execvp invocation and the path at the end of the
> >message we have a problem.  The problem is introduced by the newlib
> >execvp implementation.
> >
> >Before searching the path for the executable specified, execvp checks
> >if the path is posix or win32 style, which involves checking the
> >content of the PATH environment variable for the semicolon character
> >and also checking if the contents of the PATH starts with a single
> >letter followed by a semicolon (dos style drive) -
> >cygwin_posix_path_list_p.
> >
> >Based on the result of cygwin_posix_path_list_p execvp decides which
> >symbol to use as a path separator - semi- colon for win32 style path or
> >colon for posix style path.
> >
> >Now assume the following PATH string converted to posix - since on
> >application startup, if the user hasnt modified the PATH by himself,
> >the PATH is posix style:
> >
> >PATH=c:/jdk1.3.1/bin:/usr/local/bin:...:c:/usr/local/emacs/bin
> 
> I am not entirely sure what you're saying here, but this isn't a POSIX
> PATH.  Cygwin always converts a Windows path to a POSIX path on startup.
> A getenv() will return a posix path.  However, if you change a PATH
> to a windows path inside an application, then you will confuse cygwin
> quite a bit.

I was sure there will be a response like this - in short since as we
both
agree is posix internally (if noone messed with it) - you get this as
result
of getenv("PATH"):

c:/jdk1.3.1/bin:/usr/local/bin:...:c:/usr/local/emacs/bin

replace ... (tree dots) with all the paths in the end of previous
message
which i removed to make the path shorter ... the first element "c" is
the
one which make execvp behave bad ... it's meant to be "c" in you current 
dir you see ... but cygwin_posix_path_list_p interprets is as a drive C:
you see .. then you got a fuck up ... execvp thinks you got dos style 
PATH and tries to parse separate paths based on ';' not ':' you see..

Since there is no ';' you get the whole path list as a single path and 
the executable being searched is appended to it ...

I tried to make the previous report as detailed as i can - obviously it
was
too much since it did confused you actually .. my native language is not
english :)

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/