On Mon, 18 Feb 2019 13:15:02, Franz Fehringer wrote:
> Am 18.02.2019 um 11:42 schrieb Houder:
[snip]
> > Now show us the output of an antrun script, where the executable
> > is C:\Tools\Cygwin\bin\which and its argument: bash
>
> <exec executable="C:\Tools\Cygwin\bin\which" failonerror="true">
> <arg line="bash" />
> </exec>
> <exec executable="bash" failonerror="true">
> <arg line="-c src/main/resources/build" />
> </exec>
>
> gives
>
> [exec] /usr/bin/bash
> [exec] W i n d o w s S u b s y s t e m f o r L i n u x h a s n
> o i n s t a l l e d d i s t r i b u ti o n s .
> [exec] D i s t r i b u t i o n s c a n b e i n s t a l l e d
> b y v i s i t i n g t h e M i c r o s o f t S t o r e :
> [exec] h t t p s : / / a k a . m s / w s l s t o r e
>
> It is as if C:\Windows\System32 were hardcoded somewhere
> The ant exec documentation says
> "The <exec> task delegates to Runtime.exec which in turn apparently
> calls ::CreateProcess. It is the latter Win32 function that defines the
> exact semantics of the call. "
Erm, thinking this over ... you may be on the right track ...
After invoking the Windows executable (JVM or whatever) from Cygwin, "bash"
is started using CreateProcess()
https://docs.microsoft.com/en-us/windows/desktop/api/processthreadsapi/nf-processthreadsapi-createprocessa
Before it searches PATH, CreateProcess checks "the 32-bit Windows system
directory" for the presence of "bash.exe".
And we know that bash.exe from WSL is present in C:\Windows\System32. That
does explain why the output of bash from WSL is shown, does it not?
(reporting that a distribution is still to be installed).
The above also explains why renaming bash from WSL to "wslbash.exe" forces
CreateProcess() to search for the presence of bash.exe down the PATH.
Henri
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
