X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=VVm77pC
	fJOdD1dmiN9zK2JRotT1LaE1f1QPA9msXBly4kUBvJNxAAYOPmzVAlsLPR83/wQ8
	IzPFpLpa80JRu+VG3gAUTZv8NITYe7+OIP0xBw+4Jszk/rVIYKzgywmPvkIZ4szV
	jZj2PWR7Xn6H6MHWgRL44Rt493ikV0Xic14I=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:references:in-reply-to:from:date
	:message-id:subject:to:content-type; s=default; bh=ObJPJf53asN08
	FT+Ezw7M0MH9SI=; b=wLhKk3HdoKcAtUQ22QhV63SPzhPxrVTS1rPIaFwKddGLu
	Mm40EnQFX+cAjtnjC4ksWuwvQOogZw5csj/IVA9yqVXQxHhELi6ipxcSAj4hzZ/Z
	n26nJ+W5MOHtNz0mCceBTjihcEMQJDS4Oipgyl2vlIqJjyRloDBa7Eqx8ihDfs=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Spam-SWARE-Status:	No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:alternative, query
X-HELO:	mail-ed1-f49.google.com
MIME-Version:	1.0
References:	<CAA5t8VrSPx-LgmwCJCzTTHwA8wV6Lq5iMfjx06ApDQRPgx8ByA AT mail DOT gmail DOT com> <6cc83f4b-b0b1-d5c9-8d59-94c51382e4e3 AT gmail DOT com> <CAA5t8VoFRu2ai3c9tVTxAAVBWJg2fUMQWPr8jgjcs-67vUR60g AT mail DOT gmail DOT com> <37f0fb9b-5d70-ea1f-b1fc-1cd3f3ad0fa7 AT gmail DOT com>
In-Reply-To:	<37f0fb9b-5d70-ea1f-b1fc-1cd3f3ad0fa7@gmail.com>
From:	David Karr <davidmichaelkarr AT gmail DOT com>
Date:	Wed, 5 Dec 2018 10:33:15 -0800
Message-ID:	<CAA5t8VpcYy_tTYHTmJMmA4x3-kSJ91ZgBn0j5C=9hehKyhnxuQ@mail.gmail.com>
Subject:	Re: Redirecting stderr to stdout through pipe doesn't work the way it does in Linux
To:	The Cygwin Mailing List <cygwin AT cygwin DOT com>
X-IsSubscribed:	yes

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

> On 12/5/2018 10:11 AM, David Karr wrote:
> > On Tue, Dec 4, 2018 at 12:52 PM Marco Atzeri <marco DOT atzeri AT gmail DOT 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

- Raw text -