On Mar 16 09:15, Ilguiz Latypov wrote:
>
> > I checked this situation in cmd.exe, and it is not capable of using
> > paths relativ to %Path%. In other words, if %Path% contains a path
> > c:\foo and you have two files C:\foo\baz.exe and C:\foo\bar\baz.exe,
> > then calling "baz" works, but callin
On Wed, Mar 17, 2010 at 12:05:20PM -0600, Eric Blake wrote:
>On 03/16/2010 09:07 AM, Corinna Vinschen wrote:
>>I checked this situation in cmd.exe, and it is not capable of using
>>paths relativ to %Path%. In other words, if %Path% contains a path
>>c:\foo and you have two files C:\foo\baz.exe and
On Mar 17 12:05, Eric Blake wrote:
> On 03/16/2010 09:07 AM, Corinna Vinschen wrote:
> > I checked this situation in cmd.exe, and it is not capable of using
> > paths relativ to %Path%. In other words, if %Path% contains a path
> > c:\foo and you have two files C:\foo\baz.exe and C:\foo\bar\baz.ex
On 03/16/2010 09:07 AM, Corinna Vinschen wrote:
> I checked this situation in cmd.exe, and it is not capable of using
> paths relativ to %Path%. In other words, if %Path% contains a path
> c:\foo and you have two files C:\foo\baz.exe and C:\foo\bar\baz.exe,
> then calling "baz" works, but calling
> I checked this situation in cmd.exe, and it is not capable of using
> paths relativ to %Path%. In other words, if %Path% contains a path
> c:\foo and you have two files C:\foo\baz.exe and C:\foo\bar\baz.exe,
> then calling "baz" works, but calling "bar\baz" fails.
I only meant resolving relati
On Mar 15 12:32, Ilguiz Latypov wrote:
>
> > This has been changed deliberately, otherwise
> > the execp functions have a potential security problem. If you omit the
> > NNF flag, the function returns the original path unchanged, instead of
> > NULL.
>
> I see that my conjecture about the root c
> This has been changed deliberately, otherwise
> the execp functions have a potential security problem. If you omit the
> NNF flag, the function returns the original path unchanged, instead of
> NULL.
I see that my conjecture about the root cause of the observed inconsistency was
incorrect. B
Eric Blake a écrit :
That's bash's rules. According to POSIX, "\n" has undefined behavior.
And in some other implementations, such as Solaris sh, "\n" is
interpolated by the shell as a newline. Bash instead does the
interpolation when you use $'\n'.
isn't it the echo command which interpret
On Mar 11 20:42, Ilguiz Latypov wrote:
>
>
> On Mar 10 10:25, Corinna Vinschen wrote:
> > execv (argv[1], args);
>
> > bash$ gcc -o exec exec.c
> > bash$ ./exec /bin/echo
> > abc
> > bash$ ./exec C:\\cygwin\\bin\\echo
> > abc
> Thanks for trying a test case. I am attaching a new test case
> constness of pointers
Err, I meant constness of rvalue. But this is not related.
--
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsu
On Mar 10 10:25, Corinna Vinschen wrote:
> execv (argv[1], args);
> bash$ gcc -o exec exec.c
> bash$ ./exec /bin/echo
> abc
> bash$ ./exec C:\\cygwin\\bin\\echo
> abc
Thanks for trying a test case. I am attaching a new test case that
shows that the trouble was with execvp(), not exec().
On 03/10/2010 03:54 AM, Andy Koppe wrote:
>>> $ builtin exec "$WINDIR\system32\cmd.exe" /C echo ok
>>> -bash: exec: C:\WINDOWS\system32\cmd.exe: not found
>>>
>> Is it me, or is the quoting all wrong? Doesn't backslash in the double
>> quote (") acts as an escape character. i.e \s = s, \c = c etc.
On 03/10/2010 03:59 AM, Ilya Beylin wrote:
> Thomas, you are right, it is rather an issue with bash:
> when does not see a slash in the command name, it starts path
> searching, and of course finds nothing.
> Looks like a bug.
Not a bug. If you propose a patch to bash, then I will review and
poss
On Wed, Mar 10, 2010 at 11:59:33AM +0100, Ilya Beylin wrote:
>Thomas, you are right, it is rather an issue with bash:
>when does not see a slash in the command name, it starts path
>searching, and of course finds nothing.
>Looks like a bug.
>
>$ "$WINDIR\system32\cmd.exe" /c echo ok
>bash: C:\WINDO
Thomas, you are right, it is rather an issue with bash:
when does not see a slash in the command name, it starts path
searching, and of course finds nothing.
Looks like a bug.
$ "$WINDIR\system32\cmd.exe" /c echo ok
bash: C:\WINDOWS\system32\cmd.exe: command not found
$ "$WINDIR/system32\cmd.exe"
On 10 March 2010 10:46, Shaddy Baddah:
>> The problem is that DOS paths are treated differently, even within the
>> same program.
>> Take for instance, bash:
>>
>> $ builtin test -x "$WINDIR\system32\cmd.exe"&& echo ok
>> yes
>> $ builtin exec "$WINDIR\system32\cmd.exe" /C echo ok
>> -bash: exec:
Hi,
On 10/03/2010 10:03 AM, Ilya Beylin wrote:
The problem is that DOS paths are treated differently, even within the
same program.
Take for instance, bash:
$ builtin test -x "$WINDIR\system32\cmd.exe"&& echo ok
yes
$ builtin exec "$WINDIR\system32\cmd.exe" /C echo ok
-bash: exec: C:\WINDOWS\s
On Mar 10 11:34, Thomas Wolff wrote:
> On 10.03.2010 11:03, Ilya Beylin wrote:
> >The problem is that DOS paths are treated differently, even within the
> >same program.
> >Take for instance, bash:
> >
> >$ builtin test -x "$WINDIR\system32\cmd.exe"&& echo ok
> >yes
> >$ builtin exec "$WINDIR\syst
On 10.03.2010 11:03, Ilya Beylin wrote:
The problem is that DOS paths are treated differently, even within the
same program.
Take for instance, bash:
$ builtin test -x "$WINDIR\system32\cmd.exe"&& echo ok
yes
$ builtin exec "$WINDIR\system32\cmd.exe" /C echo ok
-bash: exec: C:\WINDOWS\system32\
The problem is that DOS paths are treated differently, even within the
same program.
Take for instance, bash:
$ builtin test -x "$WINDIR\system32\cmd.exe" && echo ok
yes
$ builtin exec "$WINDIR\system32\cmd.exe" /C echo ok
-bash: exec: C:\WINDOWS\system32\cmd.exe: not found
That makes a lot of he
On Mar 9 13:47, Ilguiz Latypov wrote:
>
> > The bottom line is that if you want to use MS-DOS
> > paths, then use a MinGW or DJGPP version of make.exe. make.exe is not
> > going to be patched.
>
> The patch was to cygwin1.dll, but I am not insisting.
Trouble is, I don't even see the problem.
> The bottom line is that if you want to use MS-DOS
> paths, then use a MinGW or DJGPP version of make.exe. make.exe is not
> going to be patched.
The patch was to cygwin1.dll, but I am not insisting.
--
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://c
On Mon, Mar 08, 2010 at 04:21:16PM -0800, Ilguiz Latypov wrote:
>The attached patch allows executing a path in backslash notation. This
>can be tested in the Cygwin builds of GNU make with the "DOS
>compatibility" compile-time option of GNU make enabled, such as those
>from Cygwin make packages 3.
The attached patch allows executing a path in backslash notation. This can be
tested in the Cygwin builds of GNU make with the "DOS compatibility"
compile-time option of GNU make enabled, such as those from Cygwin make
packages 3.79 and 3.80.
$ cat dos-compat.mak
default:
..\echo.exe
24 matches
Mail list logo
