more info on execvp problem

more info on execvp problem

[Pavel Tsekov]

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

The starting 'c' in the path looks like drive to execvp so it
decides to set the path separator to semicolon which is not
actually present in the path string - so when parsing the path 
execvp will threat the whole path as a single entity and 
passing to execv a file path like this:

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

:)

I'll suggest the attached patch although I know it is a bit
incomplete... sigh .. perhaps someone will come with a better
one. However I think the best way to fix this is too assure
that the path is always only posix style or only win32 style -
mixed style path will be very difficult to handle - to keep
the path only one of the styles (posix - since initially it's
posix) it's up the programmer in my opinion.

Thanks :)

---------------------------------------------------------------

#include <unistd.h>

int main()
{
  char *arg[] = {
    0
  };

  execvp("vi", arg);

  return 0;
}

Path:   c
        /jdk1.3.1/bin
        /usr/local/bin
        /usr/bin
        /bin
        /Oracle/Ora81/bin
        /Program Files/Oracle/jre/1.1.7/bin
        /usr/local/bin
        /usr/bin
        /usr/bin
        /dev/ant/bin
        /WINNT/system32
        /WINNT
        /WINNT/System32/Wbem
        .
        c
        /dev/ant/bin
        c
        /usr/local/emacs/bin

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

Re: more info on execvp problem

[Pavel Tsekov]

Ooops, sorry.. I forgot to attach the patch :)

Pavel Tsekov wrote:
> 
> Ok, here is what I've found about the execvp problem
> I mentiond in an earlier post:
--- execvp.c.ORIG	Mon Oct 22 11:13:55 2001
+++ execvp.c	Mon Oct 22 11:35:21 2001
@@ -11,12 +11,7 @@
 #include <errno.h>
 #include <ctype.h>
 
-#ifdef __CYGWIN32__
-static char path_delim;
-#define PATH_DELIM path_delim
-#else
 #define PATH_DELIM ':'
-#endif
 
 /*
  * Copy string, until c or <nul> is encountered.
@@ -45,6 +40,10 @@ _DEFUN (execvp, (file, argv),
 {
   char *path = getenv ("PATH");
   char buf[MAXNAMLEN];
+#ifdef __CYGWIN32__
+  int posix_path_len;
+  char *posix_path = 0;
+#endif
 
   /* If $PATH doesn't exist, just pass FILE on unchanged.  */
   if (!path)
@@ -68,7 +67,13 @@ _DEFUN (execvp, (file, argv),
 #endif
 
 #ifdef __CYGWIN32__
-  path_delim = cygwin_posix_path_list_p (path) ? ':' : ';';
+  if (strchr (path, ';'))
+    {
+      posix_path_len = cygwin_win32_to_posix_path_list_buf_size (path);
+      posix_path = (char *) malloc (posix_path_len);
+      cygwin_win32_to_posix_path_list (path, posix_path);
+      path = posix_path;
+    }
 #endif
 
   while (*path)
@@ -79,12 +84,17 @@ _DEFUN (execvp, (file, argv),
 	strcat (buf, "/");
       strcat (buf, file);
       if (execv (buf, argv) == -1 && errno != ENOENT)
-	return -1;
+	break;
       while (*path && *path != PATH_DELIM)
 	path++;
       if (*path == PATH_DELIM)
 	path++;			/* skip over delim */
     }
+
+#ifdef __CYGWIN32__
+  if (posix_path)
+    free (posix_path);
+#endif
 
   return -1;
 }

Re: more info on execvp problem

[Christopher Faylor]

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.

cgf

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

Re: more info on execvp problem

[Pavel Tsekov]

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/

Re: more info on execvp problem

[Charles Wilson]

Pavel Tsekov wrote:


> 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


Listen carefully: as Chris has already pointed out, that is NOT a posix 
path.  THIS is a posix path:

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

Or, if you have mounted C:\ as /c (like I do on my boxes):

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

See?  There are NO ':' characters EXCEPT the path delimiters in a POSIX 
PATH variable.

--Chuck



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

Re: more info on execvp problem

[Pavel Tsekov]

Charles Wilson wrote:
> 
> Pavel Tsekov wrote:
> 
> > 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
> 
> Listen carefully: as Chris has already pointed out, that is NOT a posix
> path.  THIS is a posix path:
> 
> /cygdrive/c/jdk1.3.1/bin:/usr/local/bin:...:/cygdrive/c/usr/local/emacs/bin

Now as I see a hostility in you statement I would suggest you to fire 
you debbuger and try the little test found in my first e-mail:

I try to explain that the first "c" is not drive C:

Consider the following DOS style PATH:
C;C:;C:\WINNT\System32 for exmaple
this is  

1. C directory C in current directory
2. C: for drive C: root folder

now put this path in PATH launch the debugger and see what is 
the output of getenv 

> 
> Or, if you have mounted C:\ as /c (like I do on my boxes):
> 
> /c/jdk1.3.3/bin:/usr/local/bin:...:/c/usr/local/emacs/bin
> 
> See?  There are NO ':' characters EXCEPT the path delimiters in a POSIX
> PATH variable.
> 
> --Chuck
> 
> --
> 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/

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

Re: more info on execvp problem

[Christopher Faylor]

On Mon, Oct 22, 2001 at 05:46:09PM +0200, Pavel Tsekov wrote:
>Charles Wilson wrote:
>> 
>> Pavel Tsekov wrote:
>> 
>> > 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
>> 
>> Listen carefully: as Chris has already pointed out, that is NOT a posix
>> path.  THIS is a posix path:
>> 
>> /cygdrive/c/jdk1.3.1/bin:/usr/local/bin:...:/cygdrive/c/usr/local/emacs/bin
>
>Now as I see a hostility in you statement I would suggest you to fire 
>you debbuger and try the little test found in my first e-mail:
>
>I try to explain that the first "c" is not drive C:
>
>Consider the following DOS style PATH:
>C;C:;C:\WINNT\System32 for exmaple
>this is  
>
>1. C directory C in current directory
>2. C: for drive C: root folder
>
>now put this path in PATH launch the debugger and see what is 
>the output of getenv 

The light dawned.  I finally understand.  Sorry for being so dense.

newlib's execvp had some very obsolete cygwin considerations.  It shouldn't
be trying to accomodate a Windows path.  I have no idea when that was ever
a good idea but it is definitely not a good idea now.

I've just nuked all of the strange path handling code from execvp and allowed
it to do the right thing.

Actually, hmm.  I think I'll move all of the execvp handling into cygwin where
it belongs.

cgf

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

Re: more info on execvp problem

[Charles Wilson]

Christopher Faylor wrote:


>>1. C directory C in current directory
>>2. C: for drive C: root folder
>>
>>now put this path in PATH launch the debugger and see what is 
>>the output of getenv 
>>
> 
> The light dawned.  I finally understand.  Sorry for being so dense.


Me too.  I didn't get it until now.  (However, example (1. C directory....) 
is a bad security hole.  relative paths in PATH is a *really* bad idea.)

--Chuck


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

Re: more info on execvp problem

[Don Sharp]

Charles Wilson wrote:
> 
> Pavel Tsekov wrote:
> 
> > 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
> 
> Listen carefully: as Chris has already pointed out, that is NOT a posix
> path.  THIS is a posix path:
> 
> /cygdrive/c/jdk1.3.1/bin:/usr/local/bin:...:/cygdrive/c/usr/local/emacs/bin
> 
> Or, if you have mounted C:\ as /c (like I do on my boxes):
> 
> /c/jdk1.3.3/bin:/usr/local/bin:...:/c/usr/local/emacs/bin
> 
> See?  There are NO ':' characters EXCEPT the path delimiters in a POSIX
> PATH variable.
> 
> --Chuck
> 
I think it is you that is missing the point. It is perfectly legal to
have a path like

PATH=chuck:/bin....

but if the directory happens to be called "c" rather than "chuck" then
we have the problem as the PATH would now be
PATH=c:/bin....

We either say you can't do that or deal with it.

Cheers

Don Sharp

P.S. Sorry for the personally addressed reply Chuck.

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

Re: more info on execvp problem

[Peter Buckley]

This example of 

PATH=chuck:/bin...

and 

PATH=c:/bin... 

is different from 

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

that Pavel gave. 

In Pavel's example, (which must be a typo) there would be two 
references to the directory "c". Maybe he wants two separate 
references to the same directory in the path, but I don't think 
that will accomplish anything, and it clouds the real problem, 
which I think Don has stated well here. 

HTH,
Peter 



Don Sharp wrote:
> 
> Charles Wilson wrote:
> >
> > Pavel Tsekov wrote:
> >
> > > 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
> >
> > Listen carefully: as Chris has already pointed out, that is NOT a posix
> > path.  THIS is a posix path:
> >
> > /cygdrive/c/jdk1.3.1/bin:/usr/local/bin:...:/cygdrive/c/usr/local/emacs/bin
> >
> > Or, if you have mounted C:\ as /c (like I do on my boxes):
> >
> > /c/jdk1.3.3/bin:/usr/local/bin:...:/c/usr/local/emacs/bin
> >
> > See?  There are NO ':' characters EXCEPT the path delimiters in a POSIX
> > PATH variable.
> >
> > --Chuck
> >
> I think it is you that is missing the point. It is perfectly legal to
> have a path like
> 
> PATH=chuck:/bin....
> 
> but if the directory happens to be called "c" rather than "chuck" then
> we have the problem as the PATH would now be
> PATH=c:/bin....
> 
> We either say you can't do that or deal with it.
> 
> Cheers
> 
> Don Sharp
> 
> P.S. Sorry for the personally addressed reply Chuck.
> 
> --
> 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/

-- 
Your mouse has moved.
Windows NT must be restarted for the change to take effect.
Reboot now?  [OK]

--

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

Re: more info on execvp problem

[Pavel Tsekov]

I see he things cleared now - to make the things clearer
I just want to point out that the example path I gave
the first time was based on the path of the user who first
experienced the problem - James Lee... He had the "c" three
times in his path :) So If you followed the whole discussion,
in the first mail - i presented a testcase and a path with 
which to experience the problem at the end of the mail. It
contained 3 "c"s in it .. and obviously it was the output 
of cygcheck :)

However I'm glad the problem is settled :)

Peter Buckley wrote:
> 
> This example of
> 
> PATH=chuck:/bin...
> 
> and
> 
> PATH=c:/bin...
> 
> is different from
> 
> > > > c:/jdk1.3.1/bin:/usr/local/bin:...:c:/usr/local/emacs/bin
> 
> that Pavel gave.
> 
> In Pavel's example, (which must be a typo) there would be two
> references to the directory "c". Maybe he wants two separate
> references to the same directory in the path, but I don't think
> that will accomplish anything, and it clouds the real problem,
> which I think Don has stated well here.
> 
> HTH,
> Peter
> 
> Don Sharp wrote:
> >
> > Charles Wilson wrote:
> > >
> > > Pavel Tsekov wrote:
> > >
> > > > 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
> > >
> > > Listen carefully: as Chris has already pointed out, that is NOT a posix
> > > path.  THIS is a posix path:
> > >
> > > /cygdrive/c/jdk1.3.1/bin:/usr/local/bin:...:/cygdrive/c/usr/local/emacs/bin
> > >
> > > Or, if you have mounted C:\ as /c (like I do on my boxes):
> > >
> > > /c/jdk1.3.3/bin:/usr/local/bin:...:/c/usr/local/emacs/bin
> > >
> > > See?  There are NO ':' characters EXCEPT the path delimiters in a POSIX
> > > PATH variable.
> > >
> > > --Chuck
> > >
> > I think it is you that is missing the point. It is perfectly legal to
> > have a path like
> >
> > PATH=chuck:/bin....
> >
> > but if the directory happens to be called "c" rather than "chuck" then
> > we have the problem as the PATH would now be
> > PATH=c:/bin....
> >
> > We either say you can't do that or deal with it.
> >
> > Cheers
> >
> > Don Sharp
> >
> > P.S. Sorry for the personally addressed reply Chuck.
> >
> > --
> > 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/
> 
> --
> Your mouse has moved.
> Windows NT must be restarted for the change to take effect.
> Reboot now?  [OK]
> 
> --
> 
> --
> 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/

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