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
