From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 107389 invoked by alias); 13 Sep 2017 00:11:27 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 105418 invoked by uid 89); 13 Sep 2017 00:11:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_20,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=product's, HContent-Language:en-ca, audience, generous X-HELO: nm5-vm6.access.bullet.mail.gq1.yahoo.com Received: from nm5-vm6.access.bullet.mail.gq1.yahoo.com (HELO nm5-vm6.access.bullet.mail.gq1.yahoo.com) (216.39.63.153) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Sep 2017 00:11:24 +0000 Received: from [216.39.60.167] by nm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 13 Sep 2017 00:11:22 -0000 Received: from [67.195.22.117] by tm3.access.bullet.mail.gq1.yahoo.com with NNFMP; 13 Sep 2017 00:11:22 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.gq1.yahoo.com with NNFMP; 13 Sep 2017 00:11:22 -0000 X-Yahoo-SMTP: _oUbE.SswBCQ_d_LvSIk7sZfv6R7Is8n9OVRVjJJh3dhqEgGPCs- From: "Michel LaBarre" To: References: <7ed18312-4929-8299-d186-9cb0aa541a93@redhat.com> <61150261-b3c4-d5e5-23ff-a4320a19715c@redhat.com> <502a33ed-6029-5a22-c3ff-83bd382437df@gmail.com> In-Reply-To: <502a33ed-6029-5a22-c3ff-83bd382437df@gmail.com> Subject: RE: Extra CR symbol from backticks on Cygwin 2.9.0 Date: Wed, 13 Sep 2017 00:11:00 -0000 Message-ID: <000b01d32c24$d5baf2c0$8130d840$@rogers.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00141.txt.bz2 Nikolay, there is no ASCII newline/EOL character. A "newline/EOL" is a con= text-dependent notion. The fundamental CYGWIN position (Eric, Simple, Andrey): POSIX uses LF as EO= L so POSIX-compliant behaviour in CYGWIN is to remove LF - windows be damne= d. A slightly more generous interpretation might be: POSIX removes the "EOL", which in the context of pure-POSIX is LF but in = the broader context of CYGWIN on Windows, EOL can be LF or CR-LF, so CYGWIN= might consider removing either. It would, however, break compliance with POSIX since a pure-POSIX program t= hat happens to deal with CR in its data could be broken when running on CYG= WIN. Strict POSIX compliance REQUIRES CYGWIN to strip ONLY LF unless explicitly = directed to break compliance by "igncr" - caveat emptor. Not all situations of catering to Windows norms constitute endorsing progra= mmer laziness however. Sometimes, there is no elegant or efficient alterna= tive.=20 I integrated and supplemented an enterprise backup software product in 150 = Unix(Solaris, SYSVR4) and Windows sites with the same scripts. The product'= s utilities have the same names whether in Unix or Windows but the inputs a= nd outputs adhere to the respective environments e.g. EOL varies based on t= he OS. Managing 50,000 lines of scripts (ksh, awk, perl,...) in a strictly= Unix-compliant manner would require wrappers for all utilities both obscur= ing the code and/or adding substantial overhead to convert (sometimes massi= ve) data at the shell level rather than at the OS runtime library call inte= rface invoked within the product utilities. Fortunately the tools I was us= ing (MKS) transparently handled the mapping and use of either EOL. So woul= d have "igncr" had I been using CYGWIN. (Besides EOL handling, another pervasive area was the recognition of execut= able files - in Unix by permissions and embedded codes vs name suffixes and= associations in Windows (FTYPE/ASSOC/PATHEXT). MKS's recognition of Window= s norms substantially avoided the messy workarounds; CYGWIN would not have= been so accommodating. There were other areas.) CYGWIN's fundamental purpose is to serve POSIX compliant programming under= Windows. Any deviation from this has to be via explicit directives e.g. i= gncr, lastpipe, noacl, etc..=20=20 Not trying to sound like a jerk, but I am still not clear as to why CYGWIN = users are not using Linux unless they have to support code running in both = POSIX and Windows environments in which case, the CYGWIN mission could be e= laborated to mention facilitating portability to, and integration with, Win= dows which go beyond just standards compliance. This might elevate deviati= ons, such as "igncr", from being perceived as catering to the lazy, non-pur= ist, unwashed masses rather than as genuinely valuable and essential elemen= ts of CYGWIN. Strict POSIX compliance suits developers of self-contained vertical applica= tions with minimal need for deviations; the whole application is safely ens= conced within a POSIX cocoon. On the other hand, developers integrating Wi= ndows applications and services over which they have no control may need mo= re flexibility. That being said, it has been generous on the part of CYGWIN implementors to= recognise the CYGWIN audience for whom strict POSIX compliance is secondar= y and the main objective is to have useful tools under Windows that also su= pport portability outside Windows. Thank you. Michel LaBarre=20 =20=20 > -- > cyg Simple >=20 > -- > 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