DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=cjwTAWeJk/2mcRw5
	TqHgjWteKjL3pLJfGs2e3WI+bUqbS+IJV0cMx06mhUSmfP2SgSGztzTMdqytsBvI
	rlCfpb0FfQi0I8hUjhZ2FC3KSff+nFAAjSdCkKWzPIpyGIqO8iSbIyBTR/pTQ22j
	0Mx1JapVPwRahwpufDBpAYtlILc=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Subject: Re: CR-LF handling behavior of SED changed recently - this breaks a lot of MinGW cross build scripts
To: cygwin@cygwin.com
References: <0F7D3B1B3C4B894D824F5B822E3E5A175B2636E4@IRSMSX103.ger.corp.intel.com> <a53282b6-d00c-aad8-76a6-26b4089a9623@redhat.com> <0F7D3B1B3C4B894D824F5B822E3E5A175B26CE47@IRSMSX102.ger.corp.intel.com> <59399CC5.60900@tlinx.org> <417f84ac-5d9f-dc50-e912-973e90b8a128@redhat.com> <0F7D3B1B3C4B894D824F5B822E3E5A175B26F278@IRSMSX102.ger.corp.intel.com> <34b26965-34c2-b5f0-a3f2-b2c3df344b08@gmail.com> <0F7D3B1B3C4B894D824F5B822E3E5A175B270518@IRSMSX102.ger.corp.intel.com> <5313de97-d9bd-d9c9-cb4a-254a3eadcf4a@redhat.com>
From: cyg Simple <cygsimple@gmail.com>
Message-ID: <dfe98b04-27cf-af72-5e96-7a65460c1e53@gmail.com>
Date: Sat, 10 Jun 2017 09:48:25 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <5313de97-d9bd-d9c9-cb4a-254a3eadcf4a@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit


On 6/9/2017 11:51 AM, Eric Blake wrote:
> On 06/09/2017 10:01 AM, Soegtrop, Michael wrote:
>> Dear cyg Simple,
>>
>>> but it would be most beneficial if you caused the stdio of your
>>> Windows applications to be in binary format instead of text format.  Then the
>>> CR wouldn't be an issue during the pipe process.  Why does your applications
>>> stdio need to be in text format instead of binary format?
>>
>> it is not my application I have issues with. I am building many open source tools and libraries which are maintained by others, and as you said, these others have every right to deny implementing windows specific workarounds in their tools or build scripts. Why should anybody use "wb" mode to open a file in a Linux centric app 
> 
> Using "wb" is GOOD practice in programs like tar, that WANT to produce
> their output as binary no matter what.
> 
> But you are mixing things up.  "wb" is binary mode, but manipulating CRs
> is only done in text mode.  Text mode is only possible with "wt" (a
> Cygwin extension that doesn't work elsewhere), or with "w" (depending on
> the underlying mount - on Cygwin, "w" is text on text mode mounts, and
> binary on pipelines and binary mode mounts) (on other platforms, "w" is
> always text mode, but indistinguishable from "wb" binary mode).
> 

Uhm, 'wt' and 'wb' came from MS itself.  GNU GCC was adapted to allow it
and just ignores it on systems that don't need it.

>> or mess around with the input of sed to remove CRs in a build script for such an app?
> 
> If you are writing a Linux app that processes data produced on a windows
> machine, then YOU must strip CR from that data (Linux sed will NOT strip
> it).  So now cygwin sed does the same thing.
> 
>> Of cause the same is true for cygwin, except that I think building MinGW apps is an intended use case for cygwin. 
> 
> Building mingw apps may be one use of cygwin, but it is not the
> "intended use case".  The intended use case of cygwin is to emulate as
> much as possible of a linux environment.  If building for mingw on Linux
> requires you to explicitly strip CR when dealing with data from Windows,
> then so should building for mingw on Cygwin.
> 

Exactly.  The other option is to use MSYS where this issue is dealt with.

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