AW: gawk 4.1.4: CR separate char for CRLF files

2017-08-09 Thread Roger Krebs
Hi,

I've added a BEGIN section at the beginning awk sript file setting the record 
separator explicitly for the input file (RS) as well as for the output file 
(ORS):

BEGIN {
RS="\r\n"
ORS="\r\n"
}
{
   ... your script
}

Especially the RS parameter wasn't necessary in the past but now it is.

It works in all my cases. The only disadvantage: you have to know what kind of 
files you want to handle in the awk script. The same awk script will not work 
for DOS files as well as for linux files.

Best

Roger
-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von 
Jannick
Gesendet: Mittwoch, 9. August 2017 02:48
An: cygwin@cygwin.com
Betreff: RE: gawk 4.1.4: CR separate char for CRLF files

On Tue, 08 Aug 2017 16:23:40 -0700 (PDT), Steven Penny wrote:
> On Wed, 9 Aug 2017 01:15:08, "Jannick" wrote:
> > the current version 4.1.4 of gawk appears to unpleasantly treat CR for
> > CRLF files, i.e. CR is not gracefully swallowed, but is a separate
character.
> >
> > This makes some, if not all, of the scripts we are working with here
> > useless, unless the input files are converted to LF which certainly is
> > not feasible. IIRC the issue did not show up some versions back.
> >
> > Is this a bug - or am I missing something here?
> 
> Learn to read:
> 
> http://cygwin.com/ml/cygwin/2017-08/msg00033.html

Thanks - quickly done.

The link reveals that CRLF/LF conversion is now mandatory to work with
cygwin's gawk on DOS machines. As far as I can see there is no legacy
solution like for, e.g., sed (-b switch) to have an easy solution for the
issue, especially when invoking gawk from makefiles (piping). 

I consider this bad news while admittedly not fully understanding the whole
background of the move which is not necessary for now. 


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



AW: when using cygwin version 2.8.2 the behavior of CR/LF changed completely compared to previous versions

2017-08-03 Thread Roger Krebs
Hi,

I've seen that there were some changes regarding CR/LLF in sed and cygcheck, 
but I havn't recognized that several other tool has also changed their behavior 
in the past. We haven't done an update for a longer period of time (why update 
when anything runs well) and therefor now we've been faced with several similar 
changes in the behavior of different tools. That's the reason why we've thought 
that this must be something general.

Many thanks to bring me into the right context. We've made some smaller changes 
in our scripts and everything seems to work fine now.

Again many thanks for the very quick and helpful response.

Best Regards
Roger Krebs

-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von 
David Macek
Gesendet: Mittwoch, 2. August 2017 17:46
An: cygwin@cygwin.com
Betreff: Re: when using cygwin version 2.8.2 the behavior of CR/LF changed 
completely compared to previous versions

On 2. 8. 2017 17:34, Roger Krebs wrote:
> Hi,
> 
> after updating from version 1.7.33 to version 2.8.2 the behavior of CR-LF 
> handling completely changed. This results in several srcipt errors etc.

See announcements:

* <https://cygwin.com/ml/cygwin-announce/2017-02/msg00036.html> for sed
* <https://cygwin.com/ml/cygwin-announce/2017-02/msg00035.html> for grep
* <https://cygwin.com/ml/cygwin-announce/2017-02/msg00034.html> for gawk

There was also a discussion about these changes at 
<https://cygwin.com/ml/cygwin/2017-06/msg00040.html>.

-- 
David Macek


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



when using cygwin version 2.8.2 the behavior of CR/LF changed completely compared to previous versions

2017-08-02 Thread Roger Krebs
Hi,

after updating from version 1.7.33 to version 2.8.2 the behavior of CR-LF 
handling completely changed. This results in several srcipt errors etc.

Two examples:
1) using wmic together with grep

Executing "wmic process get ExecutablePath,processID,commandline /FORMAT:CSV | 
od -t a" shows that each line from the output of wmic ends with CR CR LF. 
That's normal and works in the same way under both cygwin versions.
Executing "wmic process get ExecutablePath,processID,commandline /FORMAT:CSV | 
grep "," |od -t a" has different outputs. Under version 1.7.33 the lines ends 
with LF, under version 2.8.2 the lines still ends with CR CR LF.
If you use cut to extract the last field (the processID) you will get the pure 
processID (number) under version 1.7.33 but the processID followed by CR CR 
(string) under version 2.8.2.
When using grep CR characters at the end of the line should usually be cut of 
to make sure the $ sign can be used in regexp as end of line marker.

2) using awk and reading from DOS files
===
When reading number values from a DOS file (each line contains only a number) 
using awk and writing this number into an array variable works perfectly under 
version 1.7.33. But under version 2.8.2 all array variables are filled with the 
number followed by a CR.
   { WebOrderID[$1] = NR; }
This issue can be solved by defining RS="\r\n" in the BEGIN section of the awk 
script. But in the past it works fine without setting the record separator.

In addition we have now problems using svn under cygwin: when using a working 
copy that isn't located on a local drive but on a remote (SMB) filing system it 
will not recognized as working copy anymore. Error message:  isn't 
a valid working copy. Doing exact the same (for example "svn info") from a 
machine with cygwin 1.7.33 installed everything works fine.

First I was unsure if something general has changed since version 1.7.33 that 
has to be taken into account now. But after spending hours on reading mail 
list, FAQ and searching the internet without finding a solution I assume, this 
may be an error in cygwin. Especially because it's one of the key features of 
cygwin to map CR LF <=> LF on the fly.

I've also downgraded the cygwin.dd to version 2.8.1.1 without any change in the 
behavior. And it doesn't matter, if it is a fresh install of version 2.8.2 or 
an update from a previous version.

Also the mount point hasn't changed
Version 1.7.33
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,noacl,posix=0,noumount,auto)

Version 2.8.2:
C:/cygwin/bin on /usr/bin type ntfs (binary,auto)
C:/cygwin/lib on /usr/lib type ntfs (binary,auto)
C:/cygwin on / type ntfs (binary,auto)
C: on /cygdrive/c type ntfs (binary,noacl,posix=0,noumount,auto)

Attached you will find the "cygcheck -sv" output from version 2.8.2 as well as 
from the previously used version 1.7.33 (it's still installed on some machines).

Best Regards

Roger Krebs



Cygwin Configuration Diagnostics
Current System Time: Wed Aug 02 10:37:52 2017

Windows 2008 R2 Server Standard Ver 6.1 Build 7601 Service Pack 1

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\Windows\System32\WindowsPowerShell\v1.0

Output from C:\cygwin\bin\id.exe
UID: 112961(itse_d_operator10) GID: 100513(Domänen-Benutzer)
=100513(Domänen-Benutzer) 545(Benutzer)
544(Administratoren)   555(Remotedesktopbenutzer)
4(INTERAKTIV)  66049(KONSOLENANMELDUNG)
11(Authentifizierte Benutzer)  15(Diese Organisation)
4095(CurrentSession)   1056993(D_HAM_KoMaTo)
1054666(DE_Alle)   1064339(mediaportal-de-light)
1056937(D_CRM_Presse_Verwalter)1063234(D_HAM_SVN_User)
1057038(D_HAM_Ticket_IT)   1059959(4232 User DE SE)
1061243(D_Appl_CCBu)   1056981(D_Elektra)
1057174(D_PARMA_VERWALTER) 1071014(D_CRM_Presse_Verwalter)
1075183(D_HAM_KoMaTo)  1052553(DE_Alle)
1070980(D_PARMA_VERWALTER) 1049832(D_Elektra)
405504(Hohe Verbindlichkeitsstufe)

SysDir: C:\Windows\system32
WinDir: C:\Windows

USER = 'itse_d_operator10'
PWD = '/home/itse_d_operator10'
HOME = '/home/itse_d_operator10'

USERDOMAIN = 'SEDE'
OS = 'Windows_NT'
PROCESSOR_LEVEL = '6'
PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\'
CommonProgramW6432 = 'C:\Program Files\Common Files'
SSH_CONNECTION = '10.49.141.81 57407 10.49.143.73 22'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
FP_NO_HOST_CHECK = 'NO'
LANG = 'de_DE.UTF-8'
TZ = 'Europe/Berlin'
CommonProgramFiles = 'C:\Program Files\Common Files'
HOSTNAME = 'SDEHAMGWM11'
PUBLIC = 'C:\Users\Public