antrun versus wsl versus cygwin

antrun versus wsl versus cygwin

[Franz Fehringer]

Hi all (half off topic),

I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
the Windows component, no real Linux distribution yet).
This scenario gives me a strange problem with antrun: With <exec
executable="bash"> i always get the WSL bash instead of the Cygwin one,
although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
even so if C:/Windows/System32 (location of WSL bash) is not in the
(Cygwin) PATH at all.
I made some tries with extra parameters like seachpath to no avail.
It (naturally) works if i give the full absolute path to the Cyhwin
bash, but this is awkward.
Any hints about reason and solution?

Thanks Franz


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

Re: antrun versus wsl versus cygwin

[Thomas Wolff]

Am 17.02.2019 um 12:11 schrieb Franz Fehringer:
> Hi all (half off topic),
>
> I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
> the Windows component, no real Linux distribution yet).
> This scenario gives me a strange problem with antrun: With <exec
> executable="bash"> i always get the WSL bash instead of the Cygwin one,
> although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
> even so if C:/Windows/System32 (location of WSL bash) is not in the
> (Cygwin) PATH at all.
> I made some tries with extra parameters like seachpath to no avail.
> It (naturally) works if i give the full absolute path to the Cyhwin
> bash, but this is awkward.
> Any hints about reason and solution?
No, just about some diagnostics (maybe your application does not see the 
extended PATH?): on a Windows cmd line, say `where bash` to see if it's 
really available...

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

Re: antrun versus wsl versus cygwin

[Franz Fehringer]

Am 17.02.2019 um 13:53 schrieb Thomas Wolff:
> Am 17.02.2019 um 12:11 schrieb Franz Fehringer:
>> Hi all (half off topic),
>>
>> I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
>> the Windows component, no real Linux distribution yet).
>> This scenario gives me a strange problem with antrun: With <exec
>> executable="bash"> i always get the WSL bash instead of the Cygwin one,
>> although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
>> even so if C:/Windows/System32 (location of WSL bash) is not in the
>> (Cygwin) PATH at all.
>> I made some tries with extra parameters like seachpath to no avail.
>> It (naturally) works if i give the full absolute path to the Cyhwin
>> bash, but this is awkward.
>> Any hints about reason and solution?
> No, just about some diagnostics (maybe your application does not see the
> extended PATH?): on a Windows cmd line, say `where bash` to see if it's
> really available...
> 

I am not sure if i understand this correctly, but

Windows cmd:

C:\Users\feh01589>where bash
C:\Tools\Cygwin\bin\bash.exe
C:\Windows\System32\bash.exe

C:\Users\feh01589>`where bash`
'`where' is not recognized as an internal or external command,
operable program or batch file

Cygwin bash:

FEH01589@MU-N-566 ~
$ where bash
C:\Tools\Cygwin\bin\bash.exe
C:\Windows\System32\bash.exe

FEH01589@MU-N-566 ~
$ `where bash`
-bash: C:\Tools\Cygwin\bin\bash.exe: Kommando nicht gefunden.

where is only available as a Windows executable (not a Cygwin one).





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

Re: antrun versus wsl versus cygwin

[LRN]

[-- Attachment #1.1: Type: text/plain, Size: 901 bytes --]

On 17.02.2019 14:11, Franz Fehringer wrote:
> Hi all (half off topic),
> 
> I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
> the Windows component, no real Linux distribution yet).
> This scenario gives me a strange problem with antrun: With <exec
> executable="bash"> i always get the WSL bash instead of the Cygwin one,
> although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
> even so if C:/Windows/System32 (location of WSL bash) is not in the
> (Cygwin) PATH at all.

Tried looking in
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths"
,
"HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths"
and
"HKEY_CLASSES_ROOT\Applications\"
? They might have bash.exe in them. Also, what happens if you create a symlink
mybash.exe, that points to cygwin bash.exe? Would mybash.exe invoke the right bash?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: antrun versus wsl versus cygwin

[Houder]

On Sun, 17 Feb 2019 12:11:28, Franz Fehringer  wrote:
> Hi all (half off topic),

Not a Cygwin topic at all, I am guessing ...

> I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
> the Windows component, no real Linux distribution yet).
> This scenario gives me a strange problem with antrun: With <exec
> executable="bash"> i always get the WSL bash instead of the Cygwin one,
> although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
> even so if C:/Windows/System32 (location of WSL bash) is not in the

? "executable not in PATH", however it is found?

What is the value of PATH according to antrun? (is this ant ?????)

    https://stackoverflow.com/questions/5607580/how-to-set-the-path-environment-variable-from-ant-script
    (How to set the path environment variable from ant script)

    https://ant.apache.org/manual/Tasks/exec.html

> (Cygwin) PATH at all.
> I made some tries with extra parameters like seachpath to no avail.
> It (naturally) works if i give the full absolute path to the Cyhwin
> bash, but this is awkward.
> Any hints about reason and solution?

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

Re: antrun versus wsl versus cygwin

[Csaba Ráduly]

On 17/02/2019 12:11, Franz Fehringer wrote:
> Hi all (half off topic),
> 
> I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
> the Windows component, no real Linux distribution yet).
> This scenario gives me a strange problem with antrun: With <exec
> executable="bash"> i always get the WSL bash instead of the Cygwin one,
> although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
> even so if C:/Windows/System32 (location of WSL bash) is not in the
> (Cygwin) PATH at all.

Is this a Cygwin ant or a Windows ant ?

Csaba
-- 
You can get very substantial performance improvements
by not doing the right thing. - Scott Meyers, An Effective C++11/14 Sampler
So if you're looking for a completely portable, 100% standards-conformat way
to get the wrong information: this is what you want. - Scott Meyers (C++TDaWYK)

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

Re: antrun versus wsl versus cygwin

[Franz Fehringer]

Am 17.02.2019 um 20:09 schrieb Csaba Ráduly:
> On 17/02/2019 12:11, Franz Fehringer wrote:
>> Hi all (half off topic),
>>
>> I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
>> the Windows component, no real Linux distribution yet).
>> This scenario gives me a strange problem with antrun: With <exec
>> executable="bash"> i always get the WSL bash instead of the Cygwin one,
>> although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
>> even so if C:/Windows/System32 (location of WSL bash) is not in the
>> (Cygwin) PATH at all.
> 
> Is this a Cygwin ant or a Windows ant ?
> 
> Csaba

Windows ant via Windows maven (antrun plugin) in a Cygwin shell.


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

Re: antrun versus wsl versus cygwin

[Andrey Repin]

Greetings, Franz Fehringer!

> Am 17.02.2019 um 20:09 schrieb Csaba Ráduly:
>> On 17/02/2019 12:11, Franz Fehringer wrote:
>>> Hi all (half off topic),
>>>
>>> I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
>>> the Windows component, no real Linux distribution yet).
>>> This scenario gives me a strange problem with antrun: With <exec
>>> executable="bash"> i always get the WSL bash instead of the Cygwin one,
>>> although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
>>> even so if C:/Windows/System32 (location of WSL bash) is not in the
>>> (Cygwin) PATH at all.
>> 
>> Is this a Cygwin ant or a Windows ant ?
>> 
>> Csaba

> Windows ant via Windows maven (antrun plugin) in a Cygwin shell.

Check what Maven sets the environment to.


-- 
With best regards,
Andrey Repin
Monday, February 18, 2019 1:59:40

Sorry for my terrible english...
--
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

Re: antrun versus wsl versus cygwin

[Franz Fehringer]

Am 18.02.2019 um 00:00 schrieb Andrey Repin:
> Greetings, Franz Fehringer!
> 
>> Am 17.02.2019 um 20:09 schrieb Csaba Ráduly:
>>> On 17/02/2019 12:11, Franz Fehringer wrote:
>>>> Hi all (half off topic),
>>>>
>>>> I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
>>>> the Windows component, no real Linux distribution yet).
>>>> This scenario gives me a strange problem with antrun: With <exec
>>>> executable="bash"> i always get the WSL bash instead of the Cygwin one,
>>>> although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
>>>> even so if C:/Windows/System32 (location of WSL bash) is not in the
>>>> (Cygwin) PATH at all.
>>>
>>> Is this a Cygwin ant or a Windows ant ?
>>>
>>> Csaba
> 
>> Windows ant via Windows maven (antrun plugin) in a Cygwin shell.
> 
> Check what Maven sets the environment to.
> 
> 

I already printed out env.PATH in the antrun block and it had Cygwin bin
before Windows system32.



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

Re: antrun versus wsl versus cygwin

[Franz Fehringer]

Am 17.02.2019 um 16:07 schrieb Houder:
> On Sun, 17 Feb 2019 12:11:28, Franz Fehringer  wrote:
>> Hi all (half off topic),
> 
> Not a Cygwin topic at all, I am guessing ...
> 
>> I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
>> the Windows component, no real Linux distribution yet).
>> This scenario gives me a strange problem with antrun: With <exec
>> executable="bash"> i always get the WSL bash instead of the Cygwin one,
>> although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
>> even so if C:/Windows/System32 (location of WSL bash) is not in the
> 
> ? "executable not in PATH", however it is found?
> 
> What is the value of PATH according to antrun? (is this ant ?????)
> 
>     https://stackoverflow.com/questions/5607580/how-to-set-the-path-environment-variable-from-ant-script
>     (How to set the path environment variable from ant script)
> 
>     https://ant.apache.org/manual/Tasks/exec.html
> 
>> (Cygwin) PATH at all.
>> I made some tries with extra parameters like seachpath to no avail.
>> It (naturally) works if i give the full absolute path to the Cyhwin
>> bash, but this is awkward.
>> Any hints about reason and solution?
> 
> Henri
> 
> 

The configuration was: No system32 in the Cygwin PATH (from were maven /
antrun / ant was started) and Cygwin bin before Windows system32 in the
Windows (DOS) PATH.



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

Re: antrun versus wsl versus cygwin

[Franz Fehringer]

[-- Attachment #1.1: Type: text/plain, Size: 1205 bytes --]

Am 17.02.2019 um 15:14 schrieb LRN:
> On 17.02.2019 14:11, Franz Fehringer wrote:
>> Hi all (half off topic),
>>
>> I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
>> the Windows component, no real Linux distribution yet).
>> This scenario gives me a strange problem with antrun: With <exec
>> executable="bash"> i always get the WSL bash instead of the Cygwin one,
>> although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
>> even so if C:/Windows/System32 (location of WSL bash) is not in the
>> (Cygwin) PATH at all.
> 
> Tried looking in
> "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths"
> ,
> "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths"
> and
> "HKEY_CLASSES_ROOT\Applications\"
> ? They might have bash.exe in them. Also, what happens if you create a symlink
> mybash.exe, that points to cygwin bash.exe? Would mybash.exe invoke the right bash?
> 

There are no bash matches at the registry locations given. antrun can
execute Cygwin bash without problems (i temporally moved wsl bash.exe to
wslbash.exe), but it finds wsl bash before Cyhwin bash regardless of
PATH settings.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: antrun versus wsl versus cygwin

[Franz Fehringer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 2584 bytes --]

Am 18.02.2019 um 00:00 schrieb Andrey Repin:
> Greetings, Franz Fehringer!
> 
>> Am 17.02.2019 um 20:09 schrieb Csaba Ráduly:
>>> On 17/02/2019 12:11, Franz Fehringer wrote:
>>>> Hi all (half off topic),
>>>>
>>>> I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
>>>> the Windows component, no real Linux distribution yet).
>>>> This scenario gives me a strange problem with antrun: With <exec
>>>> executable="bash"> i always get the WSL bash instead of the Cygwin one,
>>>> although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
>>>> even so if C:/Windows/System32 (location of WSL bash) is not in the
>>>> (Cygwin) PATH at all.
>>>
>>> Is this a Cygwin ant or a Windows ant ?
>>>
>>> Csaba
> 
>> Windows ant via Windows maven (antrun plugin) in a Cygwin shell.
> 
> Check what Maven sets the environment to.
> 
> 

<echo message="XXX: ${env.PATH}"/> in the antrun block gives

     [echo] XXX:
C:\Projekte\dev\bin\gmake41;C:\Tools\VisualStudio\2017\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64;C:\Tools\VisualStudio\2017\VC\VCPackages;C:\Tools\VisualStudio\2017\MSBuild\15.0\bin\Roslyn;C:\Tools\VisualStudio\SDK\10\bin\10.0.17763.0\x64;C:\Tools\VisualStudio\SDK\10\bin\x64;C:\Tools\VisualStudio\2017\MSBuild\15.0\bin;C:\Tools\VisualStudio\2017\Common7\IDE;C:\Tools\VisualStudio\2017\Common7\Tools;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Tools\Perl\site\bin;C:\Tools\Perl\bin;C:\Tools\Cygwin\usr\local\bin;C:\Tools\Cygwin\bin;C:\Tools\apache-maven-3.6.0\bin;C:\Tools\apache-ant-1.10.5\bin;C:\winapp\openjdk\java-1.8.0-openjdk-1.8.0.191.x86_64\bin;C:\Tools\Depends64;C:\Tools\IBM\DB2\BIN;C:\Tools\IBM\DB2\FUNCTION;C:\Programs\ibm\gsk8\lib64;C:\Windows\System32\wbem;C:\Windows\System32;C:\Windows;.;C:\Projekte\dev\bin;C:\Projekte\dev\bin\userscripts;C:\Projekte\dev\LF4\LF19.1.0\utils;C:\dev\LF4\LF19.1.0\src\lfjee\lf-lc\ipl-core-lc\ipl-core-lc-sc\ipl-core-lc-sc-server\target\tbfserver\lib\cpp
     [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 t i 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

i.e. Cygwin bin before Windows system32

\0ТÒÐÐ¥\a&ö&ÆVÒ\a&W\x06÷'G3¢\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒ÷\a&ö&ÆV×2æ‡FÖÀФd\x15\x13¢\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöf\x17\x12ðФFö7VÖVçF\x17F–öã¢\x02\x02\x02\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöFö72æ‡FÖÀÐ¥Vç7V'67&–&R\x06–æfó¢\x02\x02\x02\x02\x02\x06‡GG\x03¢òö7–wv–âæ6öÒöÖÂò7Vç7V'67&–&R×6–×\x06ÆPРÐ

Re: antrun versus wsl versus cygwin

[Houder]

On Mon, 18 Feb 2019 10:25:42, Franz Fehringer  wrote:

<echo message="XXX: ${env.PATH}"/> in the antrun block gives

C:\Projekte\dev\bin\gmake41;\
C:\Tools\VisualStudio\2017\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64;\
C:\Tools\VisualStudio\2017\VC\VCPackages;\
C:\Tools\VisualStudio\2017\MSBuild\15.0\bin\Roslyn;\
C:\Tools\VisualStudio\SDK\10\bin\10.0.17763.0\x64;\
C:\Tools\VisualStudio\SDK\10\bin\x64;\
C:\Tools\VisualStudio\2017\MSBuild\15.0\bin;\
C:\Tools\VisualStudio\2017\Common7\IDE;\
C:\Tools\VisualStudio\2017\Common7\Tools;\
C:\Windows\Microsoft.NET\Framework64\v4.0.30319;\
C:\Tools\Perl\site\bin;\
C:\Tools\Perl\bin;\
C:\Tools\Cygwin\usr\local\bin;\
C:\Tools\Cygwin\bin;\
C:\Tools\apache-maven-3.6.0\bin;\
C:\Tools\apache-ant-1.10.5\bin;\
C:\winapp\openjdk\java-1.8.0-openjdk-1.8.0.191.x86_64\bin;\
C:\Tools\Depends64;\
C:\Tools\IBM\DB2\BIN;\
C:\Tools\IBM\DB2\FUNCTION;\
C:\Programs\ibm\gsk8\lib64;\
C:\Windows\System32\wbem;\
C:\Windows\System32;\
C:\Windows;\
.;\
C:\Projekte\dev\bin;\
C:\Projekte\dev\bin\userscripts;\
C:\Projekte\dev\LF4\LF19.1.0\utils;\
C:\dev\LF4\LF19.1.0\src\lfjee\lf-lc\ipl-core-lc\ipl-core-lc-sc\ipl-core-lc-sc-server\target\tbfserver\lib\cpp

Now show us the output of an antrun script, where the executable
is C:\Tools\Cygwin\bin\which and its argument: bash

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

Re: antrun versus wsl versus cygwin

[Franz Fehringer]

Am 18.02.2019 um 11:42 schrieb Houder:
> On Mon, 18 Feb 2019 10:25:42, Franz Fehringer  wrote:
> 
> <echo message="XXX: ${env.PATH}"/> in the antrun block gives
> 
> C:\Projekte\dev\bin\gmake41;\
> C:\Tools\VisualStudio\2017\VC\Tools\MSVC\14.16.27023\bin\HostX64\x64;\
> C:\Tools\VisualStudio\2017\VC\VCPackages;\
> C:\Tools\VisualStudio\2017\MSBuild\15.0\bin\Roslyn;\
> C:\Tools\VisualStudio\SDK\10\bin\10.0.17763.0\x64;\
> C:\Tools\VisualStudio\SDK\10\bin\x64;\
> C:\Tools\VisualStudio\2017\MSBuild\15.0\bin;\
> C:\Tools\VisualStudio\2017\Common7\IDE;\
> C:\Tools\VisualStudio\2017\Common7\Tools;\
> C:\Windows\Microsoft.NET\Framework64\v4.0.30319;\
> C:\Tools\Perl\site\bin;\
> C:\Tools\Perl\bin;\
> C:\Tools\Cygwin\usr\local\bin;\
> C:\Tools\Cygwin\bin;\
> C:\Tools\apache-maven-3.6.0\bin;\
> C:\Tools\apache-ant-1.10.5\bin;\
> C:\winapp\openjdk\java-1.8.0-openjdk-1.8.0.191.x86_64\bin;\
> C:\Tools\Depends64;\
> C:\Tools\IBM\DB2\BIN;\
> C:\Tools\IBM\DB2\FUNCTION;\
> C:\Programs\ibm\gsk8\lib64;\
> C:\Windows\System32\wbem;\
> C:\Windows\System32;\
> C:\Windows;\
> .;\
> C:\Projekte\dev\bin;\
> C:\Projekte\dev\bin\userscripts;\
> C:\Projekte\dev\LF4\LF19.1.0\utils;\
> C:\dev\LF4\LF19.1.0\src\lfjee\lf-lc\ipl-core-lc\ipl-core-lc-sc\ipl-core-lc-sc-server\target\tbfserver\lib\cpp
> 
> Now show us the output of an antrun script, where the executable
> is C:\Tools\Cygwin\bin\which and its argument: bash
> 
> Henri
> 
> 

<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. "






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

Re: antrun versus wsl versus cygwin

[Houder]

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
> > 
> > Henri
> > 
> > 
> 
> <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. "

This tells me that "Cygwin" is in C:\Tools\Cygwin\bin; it also tells me
that cygwin1.dll is that directory, as "which" can be invoked ...

And bash is also found in C:\Tools\Cygwin\bin, I believe. (which can be
verified by "where bash").

Consequenly Cygwin's bash can be invoked (even from a Windows JVM). It
does not matter that Runtime.exec calls ::CreateProcess.

I have no idea what "build" is or does ...

Apparently, it refers in some way to the WSL executables ...

As Windows JVM is not installed at my place (and I am using W7, where
WSL cannot be installed), I cannot help you forward beyond this point.

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

Re: antrun versus wsl versus cygwin

[Franz Fehringer]

Am 18.02.2019 um 14:07 schrieb Houder:
> 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
>>>
>>> Henri
>>>
>>>
>>
>> <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. "
> 
> This tells me that "Cygwin" is in C:\Tools\Cygwin\bin; it also tells me
> that cygwin1.dll is that directory, as "which" can be invoked ...
> 
> And bash is also found in C:\Tools\Cygwin\bin, I believe. (which can be
> verified by "where bash").
> 
> Consequenly Cygwin's bash can be invoked (even from a Windows JVM). It
> does not matter that Runtime.exec calls ::CreateProcess.
> 
> I have no idea what "build" is or does ...
> 
> Apparently, it refers in some way to the WSL executables ...
> 
> As Windows JVM is not installed at my place (and I am using W7, where
> WSL cannot be installed), I cannot help you forward beyond this point.
> 
> Henri
> 
> 

build is some simple script which does not in any way refer to wsl. The
result woould be the same without (i will check in the evening).



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

Re: antrun versus wsl versus cygwin

[Houder]

On Mon, 18 Feb 2019 14:39:11, Franz Fehringer  wrote:
> Am 18.02.2019 um 14:07 schrieb Houder:
> > On Mon, 18 Feb 2019 13:15:02, Franz Fehringer  wrote:
[snip]

> >> <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
[snip]

> > I have no idea what "build" is or does ...
> > 
> > Apparently, it refers in some way to the WSL executables ...
[snip]

> build is some simple script which does not in any way refer to wsl. The
> result woould be the same without (i will check in the evening).

build is a script ?

Drop the "-c" argument. Use "bash script" in stead in your antrun script,
like you would on the bash command line:

$ bash script

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

Re: antrun versus wsl versus cygwin

[Franz Fehringer]

Am 18.02.2019 um 17:20 schrieb Houder:
> On Mon, 18 Feb 2019 14:39:11, Franz Fehringer  wrote:
>> Am 18.02.2019 um 14:07 schrieb Houder:
>>> On Mon, 18 Feb 2019 13:15:02, Franz Fehringer  wrote:
> [snip]
> 
>>>> <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
> [snip]
> 
>>> I have no idea what "build" is or does ...
>>>
>>> Apparently, it refers in some way to the WSL executables ...
> [snip]
> 
>> build is some simple script which does not in any way refer to wsl. The
>> result woould be the same without (i will check in the evening).
> 
> build is a script ?
> 
> Drop the "-c" argument. Use "bash script" in stead in your antrun script,
> like you would on the bash command line:
> 
> $ bash script
> 
> Henri
> 
> 

Interesting idea, but no improvement.
Currently i work with the renamed (wslbash.exe) wsl bash until i (or
someone else) find(s) a better solution.



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

Re: antrun versus wsl versus cygwin

[Franz Fehringer]

Am 18.02.2019 um 17:20 schrieb Houder:
> On Mon, 18 Feb 2019 14:39:11, Franz Fehringer  wrote:
>> Am 18.02.2019 um 14:07 schrieb Houder:
>>> On Mon, 18 Feb 2019 13:15:02, Franz Fehringer  wrote:
> [snip]
> 
>>>> <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
> [snip]
> 
>>> I have no idea what "build" is or does ...
>>>
>>> Apparently, it refers in some way to the WSL executables ...
> [snip]
> 
>> build is some simple script which does not in any way refer to wsl. The
>> result woould be the same without (i will check in the evening).
> 
> build is a script ?
> 
> Drop the "-c" argument. Use "bash script" in stead in your antrun script,
> like you would on the bash command line:
> 
> $ bash script
> 
> Henri
> 
> 

Interesting idea, but no improvement.
I work wih the renamed (wslbash.exe) wsl bash in the meantime (until a
better solution is found).


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

Re: antrun versus wsl versus cygwin

[Thomas Wolff]

Am 17.02.2019 um 14:39 schrieb Franz Fehringer:
> Am 17.02.2019 um 13:53 schrieb Thomas Wolff:
>> Am 17.02.2019 um 12:11 schrieb Franz Fehringer:
>>> Hi all (half off topic),
>>>
>>> I have installed (on a Windows 10 1809 system) both Cygwin and WSL (only
>>> the Windows component, no real Linux distribution yet).
>>> This scenario gives me a strange problem with antrun: With <exec
>>> executable="bash"> i always get the WSL bash instead of the Cygwin one,
>>> although Cygwin is first in PATH (both Cygwin PATH and Windows PATH),
>>> even so if C:/Windows/System32 (location of WSL bash) is not in the
>>> (Cygwin) PATH at all.
>>> I made some tries with extra parameters like seachpath to no avail.
>>> It (naturally) works if i give the full absolute path to the Cyhwin
>>> bash, but this is awkward.
>>> Any hints about reason and solution?
>> No, just about some diagnostics (maybe your application does not see the
>> extended PATH?): on a Windows cmd line, say `where bash` to see if it's
>> really available...
>>
> I am not sure if i understand this correctly, but
>
> Windows cmd:
>
> C:\Users\feh01589>where bash
> C:\Tools\Cygwin\bin\bash.exe
> C:\Windows\System32\bash.exe
>
> ...
Try to set up a test that reproduces the original environment closely: 
start a cmd.exe from your application, just as you're trying to start 
bash. Possibly the application manipulates the path before starting an 
external command. From that (cmd started from your, whatever, ant), rerun
where bash

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

Re: antrun versus wsl versus cygwin

[Houder]

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

Re: antrun versus wsl versus cygwin

[Franz Fehringer]

Am 19.02.2019 um 00:36 schrieb Houder:
> 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
> 
> 

Yes, that is it most probably (and unfortunately).



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