RE: gawk 4.1.4: CR separate char for CRLF files

["Jannick" <thirdedition at gmx dot net>]

Hi Wolfgang,

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

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
to  
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,
etc.
> 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
processes 
on a semi-annual basis within a more than tight time frame. So cygwin's
update
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
the 
changed situation. And as you are saying below ...

> What is Unix-like or OS-like or Posix-like behaviour in that context? You
could
> argue that gawk interprets line endings like the underlying OS does (i.
e.,
> gawk reads LF in Unix and CR/LF in Win), or it interprets line endings in
a
> Unix-style no matter of the underlying OS used. That's a developer's
decision
> 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
in
> 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,
since
> 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
scripts).
> 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
gawk's
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
MS
> 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
Unix,
> 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
upgrade
> Cygwin as seldom as possible. It is a "living system", yes, which is great
on
> 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
that.
So far I was more than happy that the gawk code comes with the feature to
silently 
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
process
looking at alternatives (I listed in my first email). The evaluation in the
past
days led us to the decision to use another source of bilingual versions of
gawk 
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
LF
> 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.
Something
close to this I was having in mind in my first posting.
  
> Kind regards,
> Wolfgang

Best regards,
J.


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