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

[Marco Atzeri]

Post by 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.
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

[cyg Simple]

Post by Marco Atzeri

Post by 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.
      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.

[David Karr]

Post by David Karr

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

Post by David Karr
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.
kubectl exec pod -c container -i -t -- grep "string"

stuff.properties

Post by David Karr
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

Post by David Karr
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

[David Karr]

Post by David Karr

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

Post by David Karr
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.
kubectl exec pod -c container -i -t -- grep "string"

stuff.properties

Post by David Karr
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

Post by David Karr
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

[cyg Simple]

Post by David Karr

Post by David Karr

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

Post by David Karr
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.
kubectl exec pod -c container -i -t -- grep "string"

stuff.properties

Post by David Karr
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

Post by David Karr
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"'.

[David Karr]

Post by David Karr

Post by David Karr

Post by David Karr

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

Post by David Karr

Post by David Karr
in

Post by David Karr
Cygwin bash for scripting command-line automation. In general, this

works

Post by David Karr

Post by David Karr

Post by David Karr
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

Post by David Karr

Post by David Karr

Post by David Karr
not in Cygwin.
kubectl exec pod -c container -i -t -- grep "string"

stuff.properties

Post by David Karr
2>&1 | sed -e 's/^propname=//'
In Linux, this works perfectly fine. In Cygwin, it says "stdout is

not a

Post by David Karr

Post by David Karr

Post by David Karr
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

Post by David Karr
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

Post by David Karr
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,

Post by David Karr
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

[cyg Simple]

Post by David Karr

Post by cyg Simple
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
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?

[David Karr]

Post by cyg Simple

Post by David Karr

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

Post by David Karr
a pipeline.
If I have "winpty" prefix the call to the script that calls "kubectl", it
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

Post by David Karr
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

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

[cyg Simple]

Post by David Karr

Post by cyg Simple

Post by David Karr

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

Post by David Karr
a pipeline.
If I have "winpty" prefix the call to the script that calls "kubectl", it
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

Post by David Karr
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"?

Yes that is what I meant by my colloquial phrase.

Post by David Karr
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.

[Andrey Repin]

Greetings, David Karr!

Post by 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
winpty: error: cannot start '...': Not found in PATH

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

Post by David Karr
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

[David Karr]

Post by Andrey Repin
Greetings, David Karr!

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

Post by David Karr
a pipeline.
If I have "winpty" prefix the call to the script that calls "kubectl", it
winpty: error: cannot start '...': Not found in PATH

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

Post by David Karr
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

Post by David Karr
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.

Post by Andrey Repin
--
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