Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[David Karr]

"CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)"

I installed a version of "kubectl" for windows, and I use it extensively in
Cygwin bash for scripting command-line automation. In general, this works
perfectly fine. I even use the same scripting in a Linux VM.

I'm seeing an issue with one script that works fine in the Linux VM, but
not in Cygwin.

The command line is approximately this:

     kubectl exec pod -c container -i -t -- grep "string" stuff.properties
2>&1 | sed -e 's/^propname=//'

In Linux, this works perfectly fine.  In Cygwin, it says "stdout is not a
tty".

I haven't updated my local Cygwin installation for quite a while. I'd
prefer not to, unless there is a strong chance this kind of thing would be
fixed.

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[Marco Atzeri]

Am 04.12.2018 um 21:41 schrieb David Karr:
> "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)"
>
> I installed a version of "kubectl" for windows, and I use it extensively in
> Cygwin bash for scripting command-line automation. In general, this works
> perfectly fine. I even use the same scripting in a Linux VM.
>
> I'm seeing an issue with one script that works fine in the Linux VM, but
> not in Cygwin.
>
> The command line is approximately this:
>
>       kubectl exec pod -c container -i -t -- grep "string" stuff.properties
> 2>&1 | sed -e 's/^propname=//'
>
> In Linux, this works perfectly fine.  In Cygwin, it says "stdout is not a
> tty".
>
> I haven't updated my local Cygwin installation for quite a while. I'd
> prefer not to, unless there is a strong chance this kind of thing would be
> fixed.
>

as kubectl is not a Cygwin program, it is not aware of cygwin pty.
You can try to use winpty to overcome the problem.

https://github.com/rprichard/winpty



---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus


--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[cyg Simple]

On 12/4/2018 3:52 PM, Marco Atzeri wrote:
> Am 04.12.2018 um 21:41 schrieb David Karr:
>> "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)"
>>
>> I installed a version of "kubectl" for windows, and I use it 
>> extensively in
>> Cygwin bash for scripting command-line automation. In general, this works
>> perfectly fine. I even use the same scripting in a Linux VM.
>>
>> I'm seeing an issue with one script that works fine in the Linux VM, but
>> not in Cygwin.
>>
>> The command line is approximately this:
>>
>>       kubectl exec pod -c container -i -t -- grep "string" 
>> stuff.properties
>> 2>&1 | sed -e 's/^propname=//'
>>
>> In Linux, this works perfectly fine.  In Cygwin, it says "stdout is not a
>> tty".
>>
>> I haven't updated my local Cygwin installation for quite a while. I'd
>> prefer not to, unless there is a strong chance this kind of thing 
>> would be
>> fixed.
>>
> 
> as kubectl is not a Cygwin program, it is not aware of cygwin pty.
> You can try to use winpty to overcome the problem.
> 
> https://github.com/rprichard/winpty

Or grab the source and try to build a Cygwin version.  Looks like there 
are a number of dependencies though but primarily golang.

-- 
cyg Simple

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[David Karr]

On Tue, Dec 4, 2018 at 12:52 PM Marco Atzeri <marco.atzeri@gmail.com> wrote:

> Am 04.12.2018 um 21:41 schrieb David Karr:
> > "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)"
> >
> > I installed a version of "kubectl" for windows, and I use it extensively
> in
> > Cygwin bash for scripting command-line automation. In general, this works
> > perfectly fine. I even use the same scripting in a Linux VM.
> >
> > I'm seeing an issue with one script that works fine in the Linux VM, but
> > not in Cygwin.
> >
> > The command line is approximately this:
> >
> >       kubectl exec pod -c container -i -t -- grep "string"
> stuff.properties
> > 2>&1 | sed -e 's/^propname=//'
> >
> > In Linux, this works perfectly fine.  In Cygwin, it says "stdout is not a
> > tty".
> >
> > I haven't updated my local Cygwin installation for quite a while. I'd
> > prefer not to, unless there is a strong chance this kind of thing would
> be
> > fixed.
> >
>
> as kubectl is not a Cygwin program, it is not aware of cygwin pty.
> You can try to use winpty to overcome the problem.
>
> https://github.com/rprichard/winpty
>
>
>
>
Oh.  Senior moment.  I actually already knew that. In fact, I even have
another scripting element calling "exec" already using winpty.  Thanks for
the reminder.

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[David Karr]

On Tue, Dec 4, 2018 at 12:52 PM Marco Atzeri <marco.atzeri@gmail.com> wrote:

> Am 04.12.2018 um 21:41 schrieb David Karr:
> > "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)"
> >
> > I installed a version of "kubectl" for windows, and I use it extensively
> in
> > Cygwin bash for scripting command-line automation. In general, this works
> > perfectly fine. I even use the same scripting in a Linux VM.
> >
> > I'm seeing an issue with one script that works fine in the Linux VM, but
> > not in Cygwin.
> >
> > The command line is approximately this:
> >
> >       kubectl exec pod -c container -i -t -- grep "string"
> stuff.properties
> > 2>&1 | sed -e 's/^propname=//'
> >
> > In Linux, this works perfectly fine.  In Cygwin, it says "stdout is not a
> > tty".
> >
> > I haven't updated my local Cygwin installation for quite a while. I'd
> > prefer not to, unless there is a strong chance this kind of thing would
> be
> > fixed.
> >
>
> as kubectl is not a Cygwin program, it is not aware of cygwin pty.
> You can try to use winpty to overcome the problem.
>
> https://github.com/rprichard/winpty
>
>
>
It turns out that not only had I already used winpty for similar
functionality, it was actually in place in the pipeline when I tried to do
this.  When I turned on debugging output, it showed that kubectl was
already being wrapped by winpty when it reported "stdout is not a tty".
However, this was one shell script wrapper deeper than I usually call it.
Does it matter whether winpty is called from the shell script I'm calling,
or from the script being called by the script I'm calling?

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[cyg Simple]

On 12/5/2018 10:11 AM, David Karr wrote:
> On Tue, Dec 4, 2018 at 12:52 PM Marco Atzeri <marco.atzeri@gmail.com> wrote:
> 
>> Am 04.12.2018 um 21:41 schrieb David Karr:
>>> "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)"
>>>
>>> I installed a version of "kubectl" for windows, and I use it extensively
>> in
>>> Cygwin bash for scripting command-line automation. In general, this works
>>> perfectly fine. I even use the same scripting in a Linux VM.
>>>
>>> I'm seeing an issue with one script that works fine in the Linux VM, but
>>> not in Cygwin.
>>>
>>> The command line is approximately this:
>>>
>>>        kubectl exec pod -c container -i -t -- grep "string"
>> stuff.properties
>>> 2>&1 | sed -e 's/^propname=//'
>>>
>>> In Linux, this works perfectly fine.  In Cygwin, it says "stdout is not a
>>> tty".
>>>
>>> I haven't updated my local Cygwin installation for quite a while. I'd
>>> prefer not to, unless there is a strong chance this kind of thing would
>> be
>>> fixed.
>>>
>>
>> as kubectl is not a Cygwin program, it is not aware of cygwin pty.
>> You can try to use winpty to overcome the problem.
>>
>> https://github.com/rprichard/winpty
>>
>>
>>
> It turns out that not only had I already used winpty for similar
> functionality, it was actually in place in the pipeline when I tried to do
> this.  When I turned on debugging output, it showed that kubectl was
> already being wrapped by winpty when it reported "stdout is not a tty".
> However, this was one shell script wrapper deeper than I usually call it.
> Does it matter whether winpty is called from the shell script I'm calling,
> or from the script being called by the script I'm calling?

Your query got me interested in looking and I believe that winpty needs 
to be at the front of all the commands so that it can communicate with 
mintty properly.  To overcome the need to remember you could add an 
alias to execute the command; `alias FOO="winpty FOO"'.

-- 
cyg Simple

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[David Karr]

On Wed, Dec 5, 2018 at 9:43 AM cyg Simple <cygsimple@gmail.com> wrote:

> On 12/5/2018 10:11 AM, David Karr wrote:
> > On Tue, Dec 4, 2018 at 12:52 PM Marco Atzeri <marco.atzeri@gmail.com>
> wrote:
> >
> >> Am 04.12.2018 um 21:41 schrieb David Karr:
> >>> "CYGWIN_NT-6.1 WACDTL03DK068X 2.9.0(0.318/5/3)"
> >>>
> >>> I installed a version of "kubectl" for windows, and I use it
> extensively
> >> in
> >>> Cygwin bash for scripting command-line automation. In general, this
> works
> >>> perfectly fine. I even use the same scripting in a Linux VM.
> >>>
> >>> I'm seeing an issue with one script that works fine in the Linux VM,
> but
> >>> not in Cygwin.
> >>>
> >>> The command line is approximately this:
> >>>
> >>>        kubectl exec pod -c container -i -t -- grep "string"
> >> stuff.properties
> >>> 2>&1 | sed -e 's/^propname=//'
> >>>
> >>> In Linux, this works perfectly fine.  In Cygwin, it says "stdout is
> not a
> >>> tty".
> >>>
> >>> I haven't updated my local Cygwin installation for quite a while. I'd
> >>> prefer not to, unless there is a strong chance this kind of thing would
> >> be
> >>> fixed.
> >>>
> >>
> >> as kubectl is not a Cygwin program, it is not aware of cygwin pty.
> >> You can try to use winpty to overcome the problem.
> >>
> >> https://github.com/rprichard/winpty
> >>
> >>
> >>
> > It turns out that not only had I already used winpty for similar
> > functionality, it was actually in place in the pipeline when I tried to
> do
> > this.  When I turned on debugging output, it showed that kubectl was
> > already being wrapped by winpty when it reported "stdout is not a tty".
> > However, this was one shell script wrapper deeper than I usually call it.
> > Does it matter whether winpty is called from the shell script I'm
> calling,
> > or from the script being called by the script I'm calling?
>
> Your query got me interested in looking and I believe that winpty needs
> to be at the front of all the commands so that it can communicate with
> mintty properly.  To overcome the need to remember you could add an
> alias to execute the command; `alias FOO="winpty FOO"'.
>

Sigh. What a mess. I can't get this to work.  It was easy enough when a
single script has to execute "kubectl", having "winpty" prefix that call,
but I'm trying to write a script that calls that other script, and even in
a pipeline.

If I have "winpty" prefix the call to the script that calls "kubectl", it
says:

    winpty: error: cannot start '...': Not found in PATH

When I changed it so it references the absolute path, it then says "%1 is
not a valid Win32 application. (error 0xc1)".  So, this makes it clear that
winpty can only directly execute Windows applications, which makes sense.

So how can I call a Windows application from more than just the top-level
script?

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[cyg Simple]

On 12/5/2018 1:33 PM, David Karr wrote:
> On Wed, Dec 5, 2018 at 9:43 AM cyg Simple <cygsimple@gmail.com> wrote:
> 
>>
>> Your query got me interested in looking and I believe that winpty needs
>> to be at the front of all the commands so that it can communicate with
>> mintty properly.  To overcome the need to remember you could add an
>> alias to execute the command; `alias FOO="winpty FOO"'.
>>
> 
> Sigh. What a mess. I can't get this to work.  It was easy enough when a
> single script has to execute "kubectl", having "winpty" prefix that call,
> but I'm trying to write a script that calls that other script, and even in
> a pipeline.
> 
> If I have "winpty" prefix the call to the script that calls "kubectl", it
> says:
> 
>      winpty: error: cannot start '...': Not found in PATH
> 
> When I changed it so it references the absolute path, it then says "%1 is
> not a valid Win32 application. (error 0xc1)".  So, this makes it clear that
> winpty can only directly execute Windows applications, which makes sense.
> 
> So how can I call a Windows application from more than just the top-level
> script?
> 

What does cygcheck say about your winpty?  You are using the Cygwin 
compiled version, correct?

-- 
cyg Simple

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[David Karr]

On Wed, Dec 5, 2018 at 11:44 AM cyg Simple <cygsimple@gmail.com> wrote:

> On 12/5/2018 1:33 PM, David Karr wrote:
> > On Wed, Dec 5, 2018 at 9:43 AM cyg Simple <cygsimple@gmail.com> wrote:
> >
> >>
> >> Your query got me interested in looking and I believe that winpty needs
> >> to be at the front of all the commands so that it can communicate with
> >> mintty properly.  To overcome the need to remember you could add an
> >> alias to execute the command; `alias FOO="winpty FOO"'.
> >>
> >
> > Sigh. What a mess. I can't get this to work.  It was easy enough when a
> > single script has to execute "kubectl", having "winpty" prefix that call,
> > but I'm trying to write a script that calls that other script, and even
> in
> > a pipeline.
> >
> > If I have "winpty" prefix the call to the script that calls "kubectl", it
> > says:
> >
> >      winpty: error: cannot start '...': Not found in PATH
> >
> > When I changed it so it references the absolute path, it then says "%1 is
> > not a valid Win32 application. (error 0xc1)".  So, this makes it clear
> that
> > winpty can only directly execute Windows applications, which makes sense.
> >
> > So how can I call a Windows application from more than just the top-level
> > script?
> >
>
> What does cygcheck say about your winpty?  You are using the Cygwin
> compiled version, correct?
>

By "say", I assume you mean the output from running "cygcheck winpty"?
This is what I get:

    Found:
C:\Users\myuid\frameworks\winpty-0.4.3-cygwin-2.8.0-x64\bin\winpty.exe
    C:\Users\myuid\frameworks\winpty-0.4.3-cygwin-2.8.0-x64\bin\winpty.exe
      C:\cygwin64\bin\cygwin1.dll
        C:\Windows\system32\KERNEL32.dll
          C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
          C:\Windows\system32\ntdll.dll
          C:\Windows\system32\KERNELBASE.dll
          C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll
          C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll
      C:\Users\myuid\frameworks\winpty-0.4.3-cygwin-2.8.0-x64\bin\winpty.dll
        C:\Windows\system32\ADVAPI32.dll
          C:\Windows\system32\msvcrt.dll
            C:\Windows\system32\API-MS-Win-Core-Console-L1-1-0.dll
            C:\Windows\system32\API-MS-Win-Core-DateTime-L1-1-0.dll
          C:\Windows\system32\API-MS-WIN-Service-Core-L1-1-0.dll
          C:\Windows\system32\API-MS-WIN-Service-winsvc-L1-1-0.dll
          C:\Windows\system32\API-MS-WIN-Service-Management-L1-1-0.dll
          C:\Windows\system32\API-MS-WIN-Service-Management-L2-1-0.dll
          C:\Windows\system32\API-MS-Win-Core-LocalRegistry-L1-1-0.dll
          C:\Windows\system32\RPCRT4.dll
            C:\Windows\system32\API-MS-Win-Core-Interlocked-L1-1-0.dll
            C:\Windows\system32\API-MS-Win-Core-DelayLoad-L1-1-0.dll
        C:\Windows\system32\USER32.dll
          C:\Windows\system32\GDI32.dll
            C:\Windows\system32\LPK.dll
              C:\Windows\system32\USP10.dll


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

--
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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[Andrey Repin]

Greetings, David Karr!

> Sigh. What a mess. I can't get this to work.  It was easy enough when a
> single script has to execute "kubectl", having "winpty" prefix that call,
> but I'm trying to write a script that calls that other script, and even in
> a pipeline.

> If I have "winpty" prefix the call to the script that calls "kubectl", it
> says:

>     winpty: error: cannot start '...': Not found in PATH

Either
kubectl(){ .../winpty ...\\kubectl }; readonly -f kubectl

> When I changed it so it references the absolute path, it then says "%1 is
> not a valid Win32 application. (error 0xc1)".  So, this makes it clear that
> winpty can only directly execute Windows applications, which makes sense.

> So how can I call a Windows application from more than just the top-level
> script?

or write a Cygwin wrapper for kubectl and place it where it is usually located
on *NIX system.
Do NOT add kubectl or winpty to Cygwin $PATH, since both are not Cygwin apps
and their presence only confuses you.

Wrapper would probably be more universal.


-- 
With best regards,
Andrey Repin
Thursday, December 6, 2018 3:09:46

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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[David Karr]

On Wed, Dec 5, 2018 at 4:20 PM Andrey Repin <anrdaemon@yandex.ru> wrote:

> Greetings, David Karr!
>
> > Sigh. What a mess. I can't get this to work.  It was easy enough when a
> > single script has to execute "kubectl", having "winpty" prefix that call,
> > but I'm trying to write a script that calls that other script, and even
> in
> > a pipeline.
>
> > If I have "winpty" prefix the call to the script that calls "kubectl", it
> > says:
>
> >     winpty: error: cannot start '...': Not found in PATH
>
> Either
> kubectl(){ .../winpty ...\\kubectl }; readonly -f kubectl
>
> > When I changed it so it references the absolute path, it then says "%1 is
> > not a valid Win32 application. (error 0xc1)".  So, this makes it clear
> that
> > winpty can only directly execute Windows applications, which makes sense.
>
> > So how can I call a Windows application from more than just the top-level
> > script?
>
> or write a Cygwin wrapper for kubectl and place it where it is usually
> located
> on *NIX system.
> Do NOT add kubectl or winpty to Cygwin $PATH, since both are not Cygwin
> apps
> and their presence only confuses you.
>
> Wrapper would probably be more universal.
>

I don't see how any of this can help.  It appears that I can only "winpty"
a process if it's "at most one level deep", if that makes any sense.  I
tried writing a "kubectl" script and putting it in my path before the
Windows kubectl, and having the script execute that, and prefix the call
with "winpty".  It doesn't work if the call to "kubectl" is "deeper" in the
script chain.

What's even worse is that I didn't need "winpty" for all of the kubectl
subcommands, only "exec".  By now adding "winpty" as a prefix for all
kubectl subcommands, it messes up the output of things that just emit text.
I now have " [0K" ending all my output lines.


>
> --
> With best regards,
> Andrey Repin
> Thursday, December 6, 2018 3:09:46
>
> 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: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux

[cyg Simple]

On 12/5/2018 5:25 PM, David Karr wrote:
> On Wed, Dec 5, 2018 at 11:44 AM cyg Simple <cygsimple@gmail.com> wrote:
> 
>> On 12/5/2018 1:33 PM, David Karr wrote:
>>> On Wed, Dec 5, 2018 at 9:43 AM cyg Simple <cygsimple@gmail.com> wrote:
>>>
>>>>
>>>> Your query got me interested in looking and I believe that winpty needs
>>>> to be at the front of all the commands so that it can communicate with
>>>> mintty properly.  To overcome the need to remember you could add an
>>>> alias to execute the command; `alias FOO="winpty FOO"'.
>>>>
>>>
>>> Sigh. What a mess. I can't get this to work.  It was easy enough when a
>>> single script has to execute "kubectl", having "winpty" prefix that call,
>>> but I'm trying to write a script that calls that other script, and even
>> in
>>> a pipeline.
>>>
>>> If I have "winpty" prefix the call to the script that calls "kubectl", it
>>> says:
>>>
>>>       winpty: error: cannot start '...': Not found in PATH
>>>
>>> When I changed it so it references the absolute path, it then says "%1 is
>>> not a valid Win32 application. (error 0xc1)".  So, this makes it clear
>> that
>>> winpty can only directly execute Windows applications, which makes sense.
>>>
>>> So how can I call a Windows application from more than just the top-level
>>> script?
>>>
>>
>> What does cygcheck say about your winpty?  You are using the Cygwin
>> compiled version, correct?
>>
> 
> By "say", I assume you mean the output from running "cygcheck winpty"?
> This is what I get:
> 

Yes that is what I meant by my colloquial phrase.

>      Found:
> C:\Users\myuid\frameworks\winpty-0.4.3-cygwin-2.8.0-x64\bin\winpty.exe
>      C:\Users\myuid\frameworks\winpty-0.4.3-cygwin-2.8.0-x64\bin\winpty.exe
>        C:\cygwin64\bin\cygwin1.dll
>          C:\Windows\system32\KERNEL32.dll
>            C:\Windows\system32\API-MS-Win-Core-RtlSupport-L1-1-0.dll
>            C:\Windows\system32\ntdll.dll
>            C:\Windows\system32\KERNELBASE.dll
>            C:\Windows\system32\API-MS-Win-Core-ProcessThreads-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-Heap-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-Memory-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-Handle-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-Synch-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-File-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-IO-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-ThreadPool-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-LibraryLoader-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-NamedPipe-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-Misc-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-SysInfo-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-Localization-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-ProcessEnvironment-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-String-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-Debug-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-ErrorHandling-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-Fibers-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-Util-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-Profile-L1-1-0.dll
>            C:\Windows\system32\API-MS-Win-Security-Base-L1-1-0.dll
>        C:\Users\myuid\frameworks\winpty-0.4.3-cygwin-2.8.0-x64\bin\winpty.dll
>          C:\Windows\system32\ADVAPI32.dll
>            C:\Windows\system32\msvcrt.dll
>              C:\Windows\system32\API-MS-Win-Core-Console-L1-1-0.dll
>              C:\Windows\system32\API-MS-Win-Core-DateTime-L1-1-0.dll
>            C:\Windows\system32\API-MS-WIN-Service-Core-L1-1-0.dll
>            C:\Windows\system32\API-MS-WIN-Service-winsvc-L1-1-0.dll
>            C:\Windows\system32\API-MS-WIN-Service-Management-L1-1-0.dll
>            C:\Windows\system32\API-MS-WIN-Service-Management-L2-1-0.dll
>            C:\Windows\system32\API-MS-Win-Core-LocalRegistry-L1-1-0.dll
>            C:\Windows\system32\RPCRT4.dll
>              C:\Windows\system32\API-MS-Win-Core-Interlocked-L1-1-0.dll
>              C:\Windows\system32\API-MS-Win-Core-DelayLoad-L1-1-0.dll
>          C:\Windows\system32\USER32.dll
>            C:\Windows\system32\GDI32.dll
>              C:\Windows\system32\LPK.dll
>                C:\Windows\system32\USP10.dll
> 

I see nothing wrong here, time to ask winpty community what might be wrong.

-- 
cyg Simple

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