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:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding; q=dns; s=default; b=aBRlBhDG1D/ZN20MeySVFuA1u4N40VhSmSeKnA7cP/k OWUo0rlrRh4aTAR0GW1usapnGJiV9KR3wH654WZZEoRQro+b4RSy6FTdXxeUAUO9 E4Gn91r8XlfccXf9i/GJXpj3lH3HJ7HClGaOX0qA7TJ6CyRelEWIdfHpLYmCs2Kc = 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:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding; s=default; bh=/kq/kov4wOeuZ8kADQMQCwKn9NI=; b=dMMbU0eeE8wA/1KCL w6xhMmQd2UQINOXrmeql04nRSZ0iJiJO7WEp9939cwZIbLnnRk34cQ/7wd3/eKwP U0U5W7lX68hzTP4RZHt2wWjGv3uac7UwnsUswiIN/uuaRFQTcZ8y4y2aTfdxEOEt c5IqycxuSR/08mmvWB3o1PJ8hY= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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-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 X-Yahoo-SMTP: _oUbE.SswBCQ_d_LvSIk7sZfv6R7Is8n9OVRVjJJh3dhqEgGPCs- From: "Michel LaBarre" To: References: <7ed18312-4929-8299-d186-9cb0aa541a93 AT redhat DOT com> <61150261-b3c4-d5e5-23ff-a4320a19715c AT redhat DOT com> <502a33ed-6029-5a22-c3ff-83bd382437df AT gmail DOT com> In-Reply-To: <502a33ed-6029-5a22-c3ff-83bd382437df@gmail.com> Subject: RE: Extra CR symbol from backticks on Cygwin 2.9.0 Date: Tue, 12 Sep 2017 20:11:22 -0400 Message-ID: <000b01d32c24$d5baf2c0$8130d840$@rogers.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id v8D0BbCd007478 Nikolay, there is no ASCII newline/EOL character. A "newline/EOL" is a context-dependent notion. The fundamental CYGWIN position (Eric, Simple, Andrey): POSIX uses LF as EOL so POSIX-compliant behaviour in CYGWIN is to remove LF - windows be damned. 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 that happens to deal with CR in its data could be broken when running on CYGWIN. 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 programmer laziness however. Sometimes, there is no elegant or efficient alternative. 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 and outputs adhere to the respective environments e.g. EOL varies based on the OS. Managing 50,000 lines of scripts (ksh, awk, perl,...) in a strictly Unix-compliant manner would require wrappers for all utilities both obscuring the code and/or adding substantial overhead to convert (sometimes massive) data at the shell level rather than at the OS runtime library call interface invoked within the product utilities. Fortunately the tools I was using (MKS) transparently handled the mapping and use of either EOL. So would have "igncr" had I been using CYGWIN. (Besides EOL handling, another pervasive area was the recognition of executable files - in Unix by permissions and embedded codes vs name suffixes and associations in Windows (FTYPE/ASSOC/PATHEXT). MKS's recognition of Windows 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. igncr, lastpipe, noacl, etc.. 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 elaborated to mention facilitating portability to, and integration with, Windows which go beyond just standards compliance. This might elevate deviations, such as "igncr", from being perceived as catering to the lazy, non-purist, unwashed masses rather than as genuinely valuable and essential elements of CYGWIN. Strict POSIX compliance suits developers of self-contained vertical applications with minimal need for deviations; the whole application is safely ensconced within a POSIX cocoon. On the other hand, developers integrating Windows applications and services over which they have no control may need more 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 secondary and the main objective is to have useful tools under Windows that also support portability outside Windows. Thank you. Michel LaBarre > -- > 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