This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: gawk 4.1.4: CR separate char for CRLF files

Hi Wolfgang,

First of all, many thanks for your interesting experience report and the

On Mon, 14 Aug 2017 10:36:23 +0000, Vermessung AVT - Wolfgang Rieger wrote:
> Another solution which we have been using for many years now, though it
> might not be feasible for you:

Yes, you are right, unfortunately: We make extensive use of gawk extensions
upgraded with gawk in tandem. Thus we will move forward with the ongoing 
gawk development.

> We very rarely update Cygwin. We have been using Cygwin for some 15+
> years now. We use tools like gawk (hundreds of scripts), head, tail, sort,
> that we are using in shell scripts running under cmd.exe (no Unix shells
> involved). I soon realized that upgrades of Cygwin may cause troubles with
> existing scripts, so we only update if we really need to (e.g.: New
> functionality that would be important, 32 to 64 bit shift, eventually new
> Windows versions, bugs we needed to be fixed).
> I have followed the discussions about the CR/LF behaviour changes in the
> past attentively and decided not to update in near future, because that
> would lead to a massive problem with many hundreds of scripts - hoping
> that sometimes there will be a change in gawk again.

Agree - this is the same setting here. Furthermore, we run our heavy
on a semi-annual basis within a more than tight time frame. So cygwin's
came pretty much out of the blue in the late minute, because since the last
reporting cycle we have not used gawk. An unpleasant surprise with heavy 
potential time issues if we had not taken the decision on how to deal with
changed situation. And as you are saying below ...

> What is Unix-like or OS-like or Posix-like behaviour in that context? You
> argue that gawk interprets line endings like the underlying OS does (i.
> gawk reads LF in Unix and CR/LF in Win), or it interprets line endings in
> Unix-style no matter of the underlying OS used. That's a developer's
> in my opinion.

True. And the developers of gawk opted - with a heavy heart I believe - to 
have gawk swallow CRs.

> But since with pipes or output redirection gawk used to write no CRs even
> previous versions, we already had the problem that gawk had to accept
> *both* inputs, LF with or without CR. That worked widely fine so far,
> most Windows and other application SW we use accept both record formats,
> fortunately (we had issues with SW upgrades of other vendors no longer
> accepting pure LF, but that only concerned a very small number of
> With the new approach in Cygwin that seems to be broken, so we did not
> upgrade Cygwin since then (we currently use gawk 4.1.3).

Yes, this is our basis of SW selection process as well, but we march with
version as it nicely develops needing a gawk version reading files and pipes

of any LF and CRLF kind out of the box.

> Of course the reason for that really annoying CR/LF thing is the arrogance
> and ignorance of MS, which caused innumerable of useless developers'
> hours when I think of the endless discussions and changes in Cygwin; but
> is the one who defines the standards because of its very market power, so
> we have to deal with it, if we like or not. I'd definitely prefer to use
Unix for
> its powerful tools, but most of the SW we use is simply not available for
> and MS does not provide gawk etc. So we have to deal with that CR/LF issue
> in a pragmatic rather than in a more, say, philosophical approach: We need
> to run our scripts with as little changes as possible. So that's why we
> Cygwin as seldom as possible. It is a "living system", yes, which is great
> the one side - but can be annoying in everyday practice.

We are squared into the Windows world as well. So there's no way out of
So far I was more than happy that the gawk code comes with the feature to
swallow CRs (cf. the code reference with the exact code line in my previous 
posting) and that was used until the last update. Now that things - from our

point of view - tremendously changed, we were urged to run a decision
looking at alternatives (I listed in my first email). The evaluation in the
days led us to the decision to use another source of bilingual versions of
and friends (i.e. they read CRLF and CR without any additional hint). This
is what
the user can opt for.

> In my opinion there should be at least an option for gawk to accept both
> and CR/LF line endings equally, preferably with a system variable so that
> there is no need to change the command line call of gawk at all. That's
what I
> vote for.

Fully agree - for this I would have been pretty much in favor as well.
close to this I was having in mind in my first posting.
> Kind regards,
> Wolfgang

Best regards,

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]