Re: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux
On 12/5/2018 5:25 PM, David Karr wrote: On Wed, Dec 5, 2018 at 11:44 AM cyg Simple wrote: On 12/5/2018 1:33 PM, David Karr wrote: On Wed, Dec 5, 2018 at 9:43 AM cyg Simple 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
Re: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux
On Wed, Dec 5, 2018 at 4:20 PM Andrey Repin 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
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
On Wed, Dec 5, 2018 at 11:44 AM cyg Simple wrote: > On 12/5/2018 1:33 PM, David Karr wrote: > > On Wed, Dec 5, 2018 at 9:43 AM cyg Simple 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
On 12/5/2018 1:33 PM, David Karr wrote: On Wed, Dec 5, 2018 at 9:43 AM cyg Simple 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
On Wed, Dec 5, 2018 at 9:43 AM cyg Simple wrote: > On 12/5/2018 10:11 AM, David Karr wrote: > > On Tue, Dec 4, 2018 at 12: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 > >> > >> > >> > > 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
On 12/5/2018 10:11 AM, David Karr wrote: On Tue, Dec 4, 2018 at 12: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 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
On Tue, Dec 4, 2018 at 12: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 > > > 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
On Tue, Dec 4, 2018 at 12: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 > > > > 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
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
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