RE: gawk 4.1.4: CR separate char for CRLF files

[Jannick]

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

Re: gawk 4.1.4: CR separate char for CRLF files

[Steven Penny]

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


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

gawk 4.1.4: CR separate char for CRLF files

[Jannick]

Dear All,

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?

Thanks,
J. - living on Win10



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

Re: bash pipe fails in script with subshell/loop cmbination

[cyg Simple]

On 8/8/2017 10:59 AM, Nellis, Kenneth wrote:
> SHTDI and, sadly, such a task is not in my skill set.)
> 

Nothing like attempting to do it to add skills to your set.  This isn't
a valid reason not to do it.  It is only a valid reason that it would
take longer than someone else who might attempt it, assuming someone
else would even try for which there is no guarantee.  So if you want to
see this idea implemented, just do it.

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

Re: bash pipe fails in script with subshell/loop cmbination

[Achim Gratz]

Wouter van Doorn writes:
> I've run into a problem regarding pipes in bash, in a command that
> loops. I've reduced it to a very small one-liner that fails.

WJFFM.  Unless it's down (again) to your somewhat bizarre PATH settings,
you're most likely looking at some BLODA that tries to follow each
forked process and can't keep up at some point.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

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

RE: bash pipe fails in script with subshell/loop cmbination

[Nellis, Kenneth]

> From: Eliot Moss 
> It also works for me.  If it is not a version issue, then I
> wonder about BLODA.  Maybe anti-virus or similar tools are
> wrapping process creation in such a way that things get
> confused.  Try cygcheck, etc.

BTW, it also works for me.

With so many Cygwin issues being attributed to BLODA, I wonder 
if there is a reasonably small set of things that BLODA breaks 
that could be tested in code, and that such a bloda-checking 
program could be added to the package repertoire? (Of course, 
SHTDI and, sadly, such a task is not in my skill set.)

--Ken Nellis

Re: bash pipe fails in script with subshell/loop cmbination

[Eliot Moss]

On 8/8/2017 10:20 AM, Ronald Fischer wrote:


TWO - this fails, apparently (warning: my guess) at the pipe
$ for j in 1 2;do echo $j $(echo hello | cat);done
1
2


This works for me:

$ for j in 1 2;do echo $j $(echo hello | cat);done
1 hello
2 hello


It also works for me.  If it is not a version issue, then I
wonder about BLODA.  Maybe anti-virus or similar tools are
wrapping process creation in such a way that things get
confused.  Try cygcheck, etc.

Regards - EM

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

Re: bash pipe fails in script with subshell/loop cmbination

[Ronald Fischer]

> 
> TWO - this fails, apparently (warning: my guess) at the pipe
> $ for j in 1 2;do echo $j $(echo hello | cat);done
> 1
> 2

This works for me:

$ for j in 1 2;do echo $j $(echo hello | cat);done
1 hello
2 hello

I have:

GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)

Ronald

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

Re: bash pipe fails in script with subshell/loop cmbination

[Ronald Otto Valentin Fischer]

> 
> TWO - this fails, apparently (warning: my guess) at the pipe
> $ for j in 1 2;do echo $j $(echo hello | cat);done
> 1
> 2

This works for me:

$ for j in 1 2;do echo $j $(echo hello | cat);done
1 hello
2 hello

I have:

GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)

Ronald
-- 
Ronald Fischer 
http://www.fusshuhn.de/

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

bash pipe fails in script with subshell/loop cmbination

[Wouter van Doorn]

Hi all,

I've run into a problem regarding pipes in bash, in a command that
loops. I've reduced it to a very small one-liner that fails. The two
versions below should, I'm sure, give the same output - but they
don't. I know the command is silly and useless as it is shown here,
but it's what I'm left with from something more complex after removing
as much of the complexity as I could while retaining the actual
problem I'm fighting.

ONE - this works as expected
$ for j in 1 2;do echo $j $(echo hello);done
1 hello
2 hello

TWO - this fails, apparently (warning: my guess) at the pipe
$ for j in 1 2;do echo $j $(echo hello | cat);done
1
2

THREE - To make it that bit more obscure, the following command also
works as it should, which by now I did not expect:
$ echo hello $(echo world | cat)
hello world

If 'cat' (in TWO) is replaced by 'od -a', then od does not generate
any output (at all) either. Can someone tell me what's wrong either in
what happens or in my expectation?

I have found someone on stackexchange who may, I think, be related
(https://unix.stackexchange.com/questions/364765/store-command-output-in-variable-when-command-includes-pipes)
but unfortunately that was not resolved. I tried it with virusscanning
switched off - no difference.

Thanks for looking!

Wouter van Doorn

Cygwin Configuration Diagnostics
Current System Time: Tue Aug 08 14:49:03 2017

Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1

Path:   C:\cygwin64\home\User\exe.CYGWIN
C:\cygwin64\home\User\bin
C:\cygwin64\usr\local\bin
C:\cygwin64\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\cygwin64\bin
.

Output from C:\cygwin64\bin\id.exe
UID: 197608(User)  GID: 197121(None)
197121(None)   545(Users)
4(INTERACTIVE) 66049(CONSOLE LOGON)
11(Authenticated Users)15(This Organization)
113(Local account) 4095(CurrentSession)
66048(LOCAL)   262154(NTLM Authentication)
401408(Medium Mandatory Level)

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

Here's some environment variables that may affect cygwin:
PWD = '/cygdrive/c/users/user/desktop/bewerkt/2017/20170301/Canon G15'
HOME = '/home/User'

Here's the rest of your environment variables:
TVlines = '40'
USERDOMAIN = 'User-PC'
OS = 'Windows_NT'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
PROCESSOR_LEVEL = '6'
PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\;C:\Program 
Files (x86)\AutoIt3\AutoItX'
CommonProgramW6432 = 'C:\Program Files\Common Files'
BIN = '/home/User/bin'
BUGPLATFORM = 'CYGWIN'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
FP_NO_HOST_CHECK = 'NO'
LANG = 'en_US.UTF-8'
TZ = 'Europe/London'
i = '260_2302'
DISPLAY = ':0.0'
HOSTNAME = 'User-PC'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/cygdrive/c/users/user/desktop/bewerkt/2017/20170301'
CYGWIN_NT61 = 'GENERIC'
EDITOR = 'gvim'
USERNAME = 'User'
LOGONSERVER = '\\USER-PC'
PROCESSOR_ARCHITECTURE = 'AMD64'
EXE = '/home/User/exe.CYGWIN'
LOCALAPPDATA = 'C:\Users\User\AppData\Local'
COMPUTERNAME = 'USER-PC'
SYSTEMDRIVE = 'C:'
BUGLIB = '/home/User/c_dir/buglib'
USERPROFILE = 'C:\Users\User'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
SYSTEMROOT = 'C:\Windows'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 78 Stepping 3, GenuineIntel'
TMP = '/tmp'
HOST = 'User-PC'
windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log'
PROCESSOR_REVISION = '4e03'
tvb = '/home/User/.uxtv_6.3/tv.CYGWIN -txterm '
PROFILEREAD = 'true'
NUMBER_OF_PROCESSORS = '4'
ProgramW6432 = 'C:\Program Files'
windows_tracing_flags = '3'
uxtv_version = '6.3'
COMSPEC = 'C:\Windows\system32\cmd.exe'
APPDATA = 'C:\Users\User\AppData\Roaming'
SHELL = '/bin/bash'
TERM = 'cygwin'
PLATFORM = 'CYGWIN'
TVback = '/home/User/.tvback'
WINDIR = 'C:\Windows'
ProgramData = 'C:\ProgramData'
SHLVL = '1'
PRINTER = 'Dell C1760nw (bw)'
PROGRAMFILES = 'C:\Program Files'
TVexe = '/home/User/.tvexe'
ALLUSERSPROFILE = 'C:\ProgramData'
TEMP = '/tmp'
TVhome = '/home/User/.uxtv_6.3'
SESSIONNAME = 'Console'
ProgramFiles(x86) = 'C:\Program Files (x86)'
PS1 = 'User-PC-> '
PS2 = '-> '
HOMEDRIVE = 'C:'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info'
HOMEPATH = '\Users\User'
TVini = '/home/User/.tvexe/TVini'
ORIGINAL_PATH = 
'/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program Files/Dell/DW 
WLAN 
Card:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
 Files/WIDCOMM/Bluetooth Software:/cygdrive/c/Program Files/WIDCOMM/Bluetooth 
Software/syswow64:/cygdrive/c/Program Files/Git/cmd:/usr/bin'
MINES_HOME = '/home/User'
TVcolumns = '160'
EXECIGNORE = '*.dll'
_ = '/usr/bin/cygcheck'

Scanning registry for keys with 'Cygwin' in them...
HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Installations
  (default) = 

Python 3.6.2

[Kptain]

Hi all,

Is there any plan to update Python release and relevant libraries to last
revision: 3.6.2?
I am interesting to get some fixes included in it.

Thanks in advance,

Stefan



--
View this message in context: 
http://cygwin.1069669.n5.nabble.com/Python-3-6-2-tp135891.html
Sent from the Cygwin list mailing list archive at Nabble.com.

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

Re: Unicode width data inconsistent/outdated

[Corinna Vinschen]

On Aug  7 21:27, Thomas Wolff wrote:
> Am 07.08.2017 um 11:28 schrieb Corinna Vinschen:
> > On Aug  5 21:06, Thomas Wolff wrote:
> > > I have a working version now, and it uses much less as the category table 
> > > is
> > > range-based.
> > > Another table is needed for case conversion. Size estimates are as follows
> > > (based on Unicode 5.2 for a fair comparison, going up a little bit for 
> > > 10.0
> > > of course):
> > > 
> > > Categories: 2313 entries (10.0: 2715)
> > > each entry needs 9 bytes, total 20817 bytes
> > > I don't know whether that expands by some word-alignment.
> > > I could pack entries to 7 bytes, or even 6 bytes if that helps (total 
> > > 16191
> > > or 13878).
> > > 
> > > Case conversion: 2062 entries (10.0: 2621)
> > > each entry needs 12 bytes, total 24744
> > > packed 8 bytes, total 16496
> > > 
> > > The Categories table could be boiled down to 1223 entries (penalty: double
> > > runtime for iswupper and iswlower)
> > > The Case conversion table could be transformed to a compact form
> > > Case conversion compact: 1201 entries
> > > each entry needs 16 bytes, total 19216
> > > packed 12 or 11 (or even 10), total 14412 (or 12010)
> > > So I think the increase is acceptable for the benefit of simple and
> > > automatic generation
> > So we're at 40K+ plus code then.
> No, if I implement the packed versions, it's 19.3K, so even smaller the
> currently.

Apparently I added up wrongly.

> > > I had noticed meanwhile that this is not active in Cygwin, but it's broken
> > > anyway for multiple reasons:
> > > * platforms for which wchar_t is not Unicode should be explicitly 
> > > listed
> > > * if used, the transformation needs to be applied to all non-Unicode
> > > locales (also Chinese, Korean, and even 8-bit locales such as *.CP1252)
> > > * for towupper and towlower, the result must be back-transformed into 
> > > the
> > > respective locale encoding
> > > * particulary the locale-specific _l functions inconsistently do not 
> > > use
> > > the transformation but have this note:
> > No, no, no.  The functionality is restricted to certain use-cases and
> > always was.  It was a paid-for customer extension back in the day and it
> > was *sufficient* for the use-cases.  It's not clear how many newlib
> > users are still using it, but it's not a good idea to remove it without
> > checking first.  That means, ask on the newlib mailing list how many are
> > using the historical jp2uc code, and if we don't get a reply within,
> > say, a month, we can probably nuke it.
> OK, let's make such a request after holiday time.
> But, even if this shall persist as a special solution, it's still broken and
> should be fixed.
> Can we then substitute the current table with calling the iconvdata
> functions? In that case, as I said, the back-conversion would be available
> too, and I could fix that and add the missing handling of the _l functions,
> for a consistent solution.

I'm not quite sure I follow.  Do you mean, iconvdata tables for the
three japanese codesets only?  Wouldn't that mean to convert the
multibyte stuff into unicode and vice versa, basically getting rid
of the jp2uc workaround?

After a night's sleep, that might actually be the best way anyway.  I
agree that the jp2uc workaround is a bit of a hack.  Well, not a bit.

However, give that this does not affect Cygwin, we should really discuss
this on the newlib list.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat


signature.asc
Description: PGP signature