anybody successful in compiling apache-arrow?

[Bernd Prager]

All,

While trying to install "pyarrow" and not able to find a distribution 
package so far I was trying to compile the Apache Arrow  sources from 
https://arrow.apache.org/ under CYGWIN_NT-10.0 HW-016990 
3.1.5(0.340/5/3).


I tried:
$ mkdir release; cd release/
$ cmake .. -DARROW_JEMALLOC=OFF
$ make

It fails with:

--- snip -
[  0%] Built target toolchain
[  0%] Built target arrow_dependencies
[  1%] Building CXX object 
src/arrow/CMakeFiles/arrow_objlib.dir/array/concatenate.cc.o
In file included from 
/home/xxx/Tmp/apache-arrow-1.0.1/cpp/src/arrow/util/int_util_internal.h:30,
 from 
/home/xxx/Tmp/apache-arrow-1.0.1/cpp/src/arrow/array/concatenate.cc:39:
/home/xxx/Tmp/apache-arrow-1.0.1/cpp/src/arrow/vendored/portable-snippets/safe-math.h: 
In function ‘int psnip_safe_ulong_add(long unsigned int*, long unsigned 
int, long unsigned int)’:
/home/xxx/Tmp/apache-arrow-1.0.1/cpp/src/arrow/vendored/portable-snippets/safe-math.h:621:22: 
error: cannot convert ‘long unsigned int*’ to ‘ULONG*’ {aka ‘unsigned 
int*’}

  621 | return isf(a, b, res) == S_OK; \
  |  ^~~
  |  |
  |  long unsigned int*
/home/xxx/Tmp/apache-arrow-1.0.1/cpp/src/arrow/vendored/portable-snippets/safe-math.h:621:22: 
note: in definition of macro ‘PSNIP_SAFE_DEFINE_INTSAFE’

  621 | return isf(a, b, res) == S_OK; \
  |  ^~~
In file included from 
/home/xxx/Tmp/apache-arrow-1.0.1/cpp/src/arrow/vendored/portable-snippets/safe-math.h:126,
 from 
/home/xxx/Tmp/apache-arrow-1.0.1/cpp/src/arrow/util/int_util_internal.h:30,
 from 
/home/xxx/Tmp/apache-arrow-1.0.1/cpp/src/arrow/array/concatenate.cc:39:
/usr/include/w32api/intsafe.h:357:21: note:   initializing argument 3 of 
‘HRESULT ULongAdd(ULONG, ULONG, ULONG*)’

  357 | __MINGW_INTSAFE_API __MINGW_INTSAFE_MATH(ULongAdd, ULONG, add)
  | ^~~~
--- snip -

Now since I think this is a rather popular package I was wondering if 
anyone has gone this journey already before me.
(I noticed that Cygwin is not officially supported by Apache Arrow so 
far.)


Was anybody able to successfully compile that package? Any hints, help 
or advise?

Thank you so much,
-- Bernd


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cygwin terminal fails to start after win update

[Ken Brown via Cygwin]

On 9/2/2020 3:32 PM, Michael Moats wrote:
Hello. Loaded cygwin a few weeks ago, but after windows 10 update, mintty term 
fails to start.


Versions:
cygwin 3.1.6-1

OS Name    Microsoft Windows 10 Home
Version    10.0.19041 Build 19041

When problem first noticed:
Error: Could not fork child process: Resource temporarily unavailable (-1).
DLL rebasing may be required; see 'rebaseall / rebase --help'.
(and terminal allows no typing)

When attempt is made to add dll, bash and some other individual exceptions to 
firewall ASLR settings, Mintty starts & shell commands such as echo and pwd will 
work, but commands from /bin (i.e. ls, ln, grep, vi, cat, which) return nothing. 
Maybe more exceptions needed, but which ones?


To get cygwin working a usual, these gross windows defender firewall changes 
were made:


Windows Security
     App & browser control
         Exploit protection

Force randomization for images (Mandatory ASLR)
     Force relocation of images not compiled with /DYNAMICBASE
-> Off by default     [Mintty working]
-> On by default    [Mintyy not working]

Randomize memory allocations (Bottom-up ASLR)
     Randomize locations for virtual memory allocations.
-> Off by default     [Mintyy working]
-> On by default    [Mintyy not working]

High-entropy ASLR
     Increase variability when using Randomize memory allocations (Bottom-up 
ASLR)
-> Off by default     [Mintty working]
-> On by default    [Mintty not working]

When Cyg/Mintty is working with above gross changes:
     $ cd /usr

     $ ln -s /bin /usr/bin

     $ ls -i | grep bin
     1125899907459844 bin/
     562949954038681 sbin/

     $ cd ..

     $ ls -i | grep bin
     1125899907459844 bin/
     562949954038681 sbin/

     $ ps -ef | grep -i min
        X 649   1 ?    13:18:14 /usr/bin/mintty

Thanks in advance!!


There was a recent discussion about this issue here:

  https://sourceware.org/pipermail/cygwin/2020-August/245973.html
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] mailutils 3.10-1 (TEST)

[Ken Brown via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution
as test releases:

* mailutils-3.10-1
* libmailutils7-3.10-1
* libmailutils-sieve-extensions-3.10-1
* libmailutils-devel-3.10-1
* mailutils-mh-3.10-1
* mailutils-comsatd-3.10-1
* mailutils-imap4d-3.10-1
* mailutils-pop3d-3.10-1

Please test and report any problems to the cygwin mailing list.  If no
regressions are reported within the next few weeks, this release will
be promoted from 'test' to 'current'.

GNU Mailutils is a rich and powerful protocol-independent mail
framework.  It contains a series of useful mail libraries, clients,
and servers.  These are the primary mail utilities for the GNU system.
The central library is capable of handling electronic mail in various
mailbox formats and protocols, both local and remote.  Specifically,
this project contains a POP3 server, an IMAP4 server, and a Sieve mail
filter.  It also provides a POSIX mailx client, and a collection of
other handy tools.

This is an update to the latest upstream release.  It introduces a new
utility "decodemail", designed for converting large amounts of mail
(such as mailing list archives) to plain text representation.

These packages contain two things of possible use to Emacs users:

1. The mailutils package provides a utility /usr/bin/movemail.exe that
   Emacs's Rmail library uses.

2. The mailutils-mh package can be used by Emacs's MH-E library.  If
   you want to use this, put the line

 (load "mailutils-mh")

   in your site-start.el or ~/.emacs file.

Ken Brown
Cygwin's Mailutils maintainer
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

mailutils 3.10-1 (TEST)

[Ken Brown via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution
as test releases:

* mailutils-3.10-1
* libmailutils7-3.10-1
* libmailutils-sieve-extensions-3.10-1
* libmailutils-devel-3.10-1
* mailutils-mh-3.10-1
* mailutils-comsatd-3.10-1
* mailutils-imap4d-3.10-1
* mailutils-pop3d-3.10-1

Please test and report any problems to the cygwin mailing list.  If no
regressions are reported within the next few weeks, this release will
be promoted from 'test' to 'current'.

GNU Mailutils is a rich and powerful protocol-independent mail
framework.  It contains a series of useful mail libraries, clients,
and servers.  These are the primary mail utilities for the GNU system.
The central library is capable of handling electronic mail in various
mailbox formats and protocols, both local and remote.  Specifically,
this project contains a POP3 server, an IMAP4 server, and a Sieve mail
filter.  It also provides a POSIX mailx client, and a collection of
other handy tools.

This is an update to the latest upstream release.  It introduces a new
utility "decodemail", designed for converting large amounts of mail
(such as mailing list archives) to plain text representation.

These packages contain two things of possible use to Emacs users:

1. The mailutils package provides a utility /usr/bin/movemail.exe that
   Emacs's Rmail library uses.

2. The mailutils-mh package can be used by Emacs's MH-E library.  If
   you want to use this, put the line

 (load "mailutils-mh")

   in your site-start.el or ~/.emacs file.

Ken Brown
Cygwin's Mailutils maintainer

Re: Using cygwin tar from a DOS window

[Bill Stewart]

On Wed, Sep 2, 2020 at 3:30 PM Wayne Davison wrote:

Something like this seems to work fine (with very minimal testing):
>
> @echo off
> PATH=C:\cygwin64\bin
> C:\cygwin64\bin\tar %*
>

Keeping in mind that cmd.exe provides no environment variable scoping using
scripts, I would recommend setlocal/endlocal; example:

@echo off
setlocal enableextensions
rem set CYGPATH to cygwin "/bin" directory
set CYGPATH=C:\cygwin64\bin
set Path=%CYGPATH%;%Path%
"%CYGPATH%\tar" %*
endlocal

Bill
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Using cygwin tar from a DOS window

[Wayne Davison]

On Wed, Sep 2, 2020 at 7:58 AM Douglas Coup wrote:
> I need the Cygwin tar to be found regardless of whether I'm using a
> Cygwin command window or a DOS command window.

I think the easiest way to run the cygwin tar from CMD (if you don't
want to just put your cygwin bin dir on your Windows PATH) is to
create a bat file that calls the cygwin tar. That way you always get
the latest cygwin tar & dll versions from the main install.  Something
like this seems to work fine (with very minimal testing):

@echo off
PATH=C:\cygwin64\bin
C:\cygwin64\bin\tar %*

..wayne..
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: wish8.6 perfect in Cygwin32, misbehaves in Cygwin64

[Marco Atzeri via Cygwin]

On 02.09.2020 22:46, Fergus Daly via Cygwin wrote:

Can't entirely recall* when wish8.4 was versioned up to the current wish8.6 in 
Cygwin,
or whether there was an intermediate wish8.5 - I think it must be nearly a 
decade ago, or possibly
longer - but I do remember that
1. wish8.4 "worked" in bash and rxvt terminals (I think all this preceded 
mintty) AND also in xterm
2. wish8.[56] "fails" in bash and mintty terminals and insists on DISPLAY being 
set, i.e. requires XWin
(by which I mean wish was the driver for Tcl/Tk menus, windows, other displays).
Actually I hung on to the components that comprise wish8.4 and toggle between 
them at will and can
confirm  the truth of (1) and (2) above.
Generally though, I guess users have upgraded to wish8.6 long since and if they 
use it to provide Tcl/Tk
menus (?) or sidebar Help Tcl/Tk windows (?) are used to requiring e.g. xterm 
in XWin in order to do so.



can you please provide a test case ?

If I remember right the graphic was moved long time ago from GDI to X11
due to the burden to do maintain the GDI fork.


ALL THIS in Cygwin-32.

Recent unconnected threads in this list have persuaded me to trial Cygwin-64 
(and, if happy, I'll jettison the
Cygwin-32 platform). I have installed it identically (see setup -P below).
The many contexts in which wish8.6 has worked properly in Cygwin-32 are, for 
me, failing uniformly in
Cygwin-64. By this I mean, Tcl/Tk menus are mutely failing to appear, Tcl/Tk 
Help windows are mutely failing
to appear.
Can't think what I'm getting wrong. But a good first step would be: have any of 
you, in advancing from Cygwin-32
to what was intended to provide identical functionality in Cygwin-64, 
experienced similar unexplained glitches,
and managed to solve them? Or is this experience unique? If you can help with 
this specific Tcl/Tk problem, that
would be perfect!


almost all has been ported from 32 to 64 and works
The very few exceptions are dead applications


BTW I use
setup-x86[_64] -P ..,..,tcl-tix,tcl-tk-devel,..,..
to build the supporting platforms.
Thank you!

* "Can't entirely recall .. .." (line 1):
Typing "site:cygwin.com searchstring" into the Google search bar used to yield 
pages of output, including hits for
very specific strings e.g. "site:cygwin.com fergus grap" to remind myself what 
I asked about grap as long ago as
2001 - and, much more helpfully, what somebody kindly answered.  Now, after a 
measly trickle of hits, Google
explains the paucity with a reference to data protection. I know I asked 
specifically about the loss of versatility
with wish8.4 at the time, but cannot find the thread.
Is there a vehicle which still permits an exhaustive search of the entire 
Cygwin project mailing archive?



you can still download all the raw data   :-(
https://cygwin.com/pipermail/cygwin/
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ITP] python-getdevinfo

[Hamish McIntyre-Bhatty via Cygwin-apps]

On 02/09/2020 19:05, Marco Atzeri via Cygwin-apps wrote:
>
> Hi Hamish,
>
> it builds fine and there are no problem on tests.
>
> Are you missing some dependencies ?
>
>  "On Cygwin, you need the smartmontools and blkid packages".
>
> but they are not there:
>
>  $ cygport python-getdevinfo.cygport deps|cat
> python36-3.6.10-1
> python36-bs4-4.9.1-1
> python36-getdevinfo-1.1.0-1
> python37-3.7.7-1
> python37-bs4-4.9.1-1
> python37-getdevinfo-1.1.0-1
> python38-3.8.3-1
> python38-bs4-4.9.1-1
> python38-getdevinfo-1.1.0-1
>
>
> Is already in some Linux distribution ?
> Otherwise we need 5 votes from maintainers

Hi Marco,

Thanks for testing again :)

Ah yes, I'm not sure how I managed to do that, they should be in the
cygport file. I'll sort that out tomorrow and notify this list again.

It's not currently in the official repositories of a Linux distro no.
I'm essentially only packaging this for Cygwin because it's a dependency
for DDRescue-GUI, a GUI I wrote for GNU ddrescue. I currently release
for Linux and macOS, and there has been demand for Cygwin, hence me
getting involved with all of this in the beginning really. I would very
much appreciate it if I could get 5 votes, but if not I'll create some
kind of bundle instead. I understand that this is your project and you
may not all want my program in it :)

NB: In programs that bundle cygwin.dll, are the /dev and /cygdrive
folders visible to access devices? I'm hoping the answer is yes because
otherwise my bundle idea probably won't work.

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: set up error, Any ideas?

[cygwinautoreply--- via Cygwin]

>C:\WINDOWS\system32>cntlm -H -c C:\Program Files (x86)\Cntlm\cntlm.ini
>  0 [main] cntlm 20512 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
> pointer.  Please report this problem to
>the public mailing list cygwin@cygwin.com
>Exitting with error. Check daemon logs or run with -v.

>Thank you,

>A. Randall Hansen Senior Software Engineer
>Intermountain Healthcare Clinical Information Systems
>(385) 297 6089
>randall.han...@imail.org

>NOTICE: This e-mail is for the sole use of the intended recipient and may 
>contain confidential and privileged information. If you are not the intended 
>recipient, you are prohibited from reviewing, using, disclosing or 
>distributing this e-mail or its contents. If you have received this e-mail in 
>error, please contact the sender by reply e-mail and destroy all copies of 
>this e-mail and its contents.

https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

set up error, Any ideas?

[Randall Hansen via Cygwin]

C:\WINDOWS\system32>cntlm -H -c C:\Program Files (x86)\Cntlm\cntlm.ini
  0 [main] cntlm 20512 find_fast_cwd: WARNING: Couldn't compute FAST_CWD 
pointer.  Please report this problem to
the public mailing list cygwin@cygwin.com
Exitting with error. Check daemon logs or run with -v.

Thank you,

A. Randall Hansen Senior Software Engineer
Intermountain Healthcare Clinical Information Systems
(385) 297 6089
randall.han...@imail.org

NOTICE: This e-mail is for the sole use of the intended recipient and may 
contain confidential and privileged information. If you are not the intended 
recipient, you are prohibited from reviewing, using, disclosing or distributing 
this e-mail or its contents. If you have received this e-mail in error, please 
contact the sender by reply e-mail and destroy all copies of this e-mail and 
its contents.
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

RE: [cygwin] ssh server immediately closing connection

[Jason Pyeron]

> -Original Message-
> From: Leroy Tennison
> Sent: Wednesday, September 2, 2020 3:49 PM
> 
> Attempting to connect using blah@1.2.3.4 (the user and IP address have been 
> obfuscated), the first
> time I'm prompted to accept the host's fingerprint and, after I do, the 
> connection is immediately
> closed.  Trying again I get an immediate "Connection closed by 1.2.3.4 port 
> 22".  I have tried both
> 32-bit and 64-bit Cygwin (after removing what was previously installed).  I 
> used ssh-host-config and
> ssh-user-config for setup, the lines in sshd_config which aren't commented 
> out are:
> 
> StrictModes no
> AuthorizedKeysFile  .ssh/authorized_keys
> Subsystem   sftp/usr/sbin/sftp-server

Please detail the windows service configuration. I see that you are running as 
cyg_server account. Please try as SYSTEM.

Please confirm the issue is the same in the windows event log 

-Jason

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

ssh server immediately closing connection

[Leroy Tennison]

Attempting to connect using blah@1.2.3.4 (the user and IP address have been 
obfuscated), the first time I'm prompted to accept the host's fingerprint and, 
after I do, the connection is immediately closed.  Trying again I get an 
immediate "Connection closed by 1.2.3.4 port 22".  I have tried both 32-bit and 
64-bit Cygwin (after removing what was previously installed).  I used 
ssh-host-config and ssh-user-config for setup, the lines in sshd_config which 
aren't commented out are:

StrictModes no
AuthorizedKeysFile      .ssh/authorized_keys
Subsystem       sftp    /usr/sbin/sftp-server

In troubleshooting I stopped the Cygwin sshd service, used "Run as 
Administrator" for a command prompt, then ran cygwin.bat and afterward ran: 
/usr/sbin/sshd -d -de -f /etc/sshd_config.  The result was "seteuid 1050745: 
Operation not permitted" right before the server shut down.

Searching the web indicated the problem might be that the service account 
didn't have "Act as part of the operating system" and "create a token object" 
privileges although the situation was different (I'm not consciously using 
LSA).  However, running the service as the local system account and a created 
user account with these privileges (and being a member of the Administrators 
group) produced the same result.

In the attached file I have replaced the real user ID with "blah" and part of 
the domain/host name with XYZQ using vi's search-and-replace.  No other changes 
were made.

Are there other troubleshooting steps I can take or a solution to this issue?  
Thanks for your help.
Leroy Tennison
Network Information/Cyber Security Specialist
E: le...@datavoiceint.com
2220 Bush Dr
McKinney, Texas
75070
www.datavoiceint.com
This message has been sent on behalf of a company that is part of the Harris 
Operating Group of Constellation Software Inc.If you prefer not to be contacted 
by Harris Operating Group please notify us.
This message is intended exclusively for the individual or entity to which it 
is addressed. This communication may contain information that is proprietary, 
privileged or 
confidential or otherwise legally exempt from disclosure. If you are not the 
named addressee, you are not authorized to read, print, retain, copy or 
disseminate this message or any part of it. If you have received this message 
in error, please notify the sender immediately by e-mail and delete all copies 
of the message.
 


cygcheck.out
Description: cygcheck.out
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Cygwin terminal fails to start after win update

[Michael Moats]

Hello. Loaded cygwin a few weeks ago, but after windows 10 update, 
mintty term fails to start.


Versions:
cygwin 3.1.6-1

OS Name    Microsoft Windows 10 Home
Version    10.0.19041 Build 19041

When problem first noticed:
Error: Could not fork child process: Resource temporarily unavailable (-1).
DLL rebasing may be required; see 'rebaseall / rebase --help'.
(and terminal allows no typing)

When attempt is made to add dll, bash and some other individual 
exceptions to firewall ASLR settings, Mintty starts & shell commands 
such as echo and pwd will work, but commands from /bin (i.e. ls, ln, 
grep, vi, cat, which) return nothing. Maybe more exceptions needed, but 
which ones?


To get cygwin working a usual, these gross windows defender firewall 
changes were made:


Windows Security
    App & browser control
        Exploit protection

Force randomization for images (Mandatory ASLR)
    Force relocation of images not compiled with /DYNAMICBASE
-> Off by default     [Mintty working]
-> On by default    [Mintyy not working]

Randomize memory allocations (Bottom-up ASLR)
    Randomize locations for virtual memory allocations.
-> Off by default     [Mintyy working]
-> On by default    [Mintyy not working]

High-entropy ASLR
    Increase variability when using Randomize memory allocations 
(Bottom-up ASLR)

-> Off by default     [Mintty working]
-> On by default    [Mintty not working]

When Cyg/Mintty is working with above gross changes:
    $ cd /usr

    $ ln -s /bin /usr/bin

    $ ls -i | grep bin
    1125899907459844 bin/
    562949954038681 sbin/

    $ cd ..

    $ ls -i | grep bin
    1125899907459844 bin/
    562949954038681 sbin/

    $ ps -ef | grep -i min
       X 649   1 ?    13:18:14 /usr/bin/mintty

Thanks in advance!!

-- Michael Moats


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Using cygwin tar from a DOS window

[Thomas Wolff]

Am 02.09.2020 um 19:59 schrieb Eliot Moss:

On 9/2/2020 1:40 PM, Douglas Coup wrote:


On 9/2/2020 1:28 PM, Eliot Moss wrote:

On 9/2/2020 1:00 PM, Douglas Coup wrote:


On 9/2/2020 12:53 PM, Bill Stewart wrote:

On Wed, Sep 2, 2020 at 8:58 AM Douglas Coup wrote:

But if I use tar from a DOS window ...
Surely you don't mean DOS? DOS doesn't exist in Windows any more 
(unless

you are using an emulator like DosBox or a VM).

Do you mean a cmd.exe console window? (cmd.exe is a Windows 
console-mode

program that, despite appearances, is not "DOS." DOS was a real-mode
single-tasking operating system.)

Bill
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Yes, a cmd.exe console window.


Hardly the point :-) ...

But I think your problem may be that the Cygwin dlls need to be on 
the search path,
and you're hoping that none of them have names that are the same as 
ones earlier on

the path ...

Best - Eliot Moss
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


I did try copying all of the .dll files in the Cygwin bin folder to 
the same folder where the copy of Cygwin's tar.exe sits. That folder 
appears first in the PATH.  But despite that, trying to invoke tar 
from the cmd window still pops up the window saying cyggcc_s-1.dll 
can't be found.


I meant that your PATH should have the Cygwin bin folder in it, 
somewhere.  Does that not work for you?  But my setup definitely has 
the cyggcc_s-1.dll file in /bin and /usr/bin.

It comes from the libgcc1 package (libgcc1-9.3.0-2 in my case).

Some independent comments:
* I see cyggcc_s-seh-1.dll in the libgcc1 package, not cyggcc_s-1.dll
* My current cygwin tar does not depend on cyggcc_s-1.dll
* Maybe your cygwin tar is an older release, now and then gcc library 
conventions have changed

Thomas
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ITP] python-getdevinfo

[Marco Atzeri via Cygwin-apps]

On 02.09.2020 17:29, Hamish McIntyre-Bhatty via Cygwin-apps wrote:

*bump* in case this has not been seen.

Hamish

On 26/08/2020 10:35, Hamish McIntyre-Bhatty via Cygwin-apps wrote:

Okay, I have updated the packages (same location:
https://www.hamishmb.com/files/cygwin-temp/). It should now handle fork
errors better.

If it fails again, please post the full output from the test command so
I can see what version(s) of Python the tests are failing on. It might
be useful for someone else to have a go as well - would be good to know
multiple people can reproduce this issue as I have still had no luck
doing that.



Hi Hamish,

it builds fine and there are no problem on tests.

Are you missing some dependencies ?

 "On Cygwin, you need the smartmontools and blkid packages".

but they are not there:

 $ cygport python-getdevinfo.cygport deps|cat
python36-3.6.10-1
python36-bs4-4.9.1-1
python36-getdevinfo-1.1.0-1
python37-3.7.7-1
python37-bs4-4.9.1-1
python37-getdevinfo-1.1.0-1
python38-3.8.3-1
python38-bs4-4.9.1-1
python38-getdevinfo-1.1.0-1


Is already in some Linux distribution ?
Otherwise we need 5 votes from maintainers

Re: Using cygwin tar from a DOS window

[Eliot Moss]

On 9/2/2020 1:40 PM, Douglas Coup wrote:


On 9/2/2020 1:28 PM, Eliot Moss wrote:

On 9/2/2020 1:00 PM, Douglas Coup wrote:


On 9/2/2020 12:53 PM, Bill Stewart wrote:

On Wed, Sep 2, 2020 at 8:58 AM Douglas Coup wrote:

But if I use tar from a DOS window ...
Surely you don't mean DOS? DOS doesn't exist in Windows any more (unless
you are using an emulator like DosBox or a VM).

Do you mean a cmd.exe console window? (cmd.exe is a Windows console-mode
program that, despite appearances, is not "DOS." DOS was a real-mode
single-tasking operating system.)

Bill
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Yes, a cmd.exe console window.


Hardly the point :-) ...

But I think your problem may be that the Cygwin dlls need to be on the search 
path,
and you're hoping that none of them have names that are the same as ones 
earlier on
the path ...

Best - Eliot Moss
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


I did try copying all of the .dll files in the Cygwin bin folder to the same folder where the copy 
of Cygwin's tar.exe sits.  That folder appears first in the PATH.  But despite that, trying to 
invoke tar from the cmd window still pops up the window saying cyggcc_s-1.dll can't be found.


I meant that your PATH should have the Cygwin bin folder in it, somewhere.  Does that not work for 
you?  But my setup definitely has the cyggcc_s-1.dll file in /bin and /usr/bin.

It comes from the libgcc1 package (libgcc1-9.3.0-2 in my case).

Eliot Moss
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Using cygwin tar from a DOS window

[Bill Stewart]

On Wed, Sep 2, 2020 at 11:40 AM Douglas Coup wrote:

I did try copying all of the .dll files in the Cygwin bin folder to the
> same folder where the copy of Cygwin's tar.exe sits.
>

Why is this step necessary? Is the cygwin install process not working?

Bill
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Using cygwin tar from a DOS window

[Douglas Coup]

On 9/2/2020 1:28 PM, Eliot Moss wrote:

On 9/2/2020 1:00 PM, Douglas Coup wrote:


On 9/2/2020 12:53 PM, Bill Stewart wrote:

On Wed, Sep 2, 2020 at 8:58 AM Douglas Coup wrote:

But if I use tar from a DOS window ...
Surely you don't mean DOS? DOS doesn't exist in Windows any more 
(unless

you are using an emulator like DosBox or a VM).

Do you mean a cmd.exe console window? (cmd.exe is a Windows 
console-mode

program that, despite appearances, is not "DOS." DOS was a real-mode
single-tasking operating system.)

Bill
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Yes, a cmd.exe console window.


Hardly the point :-) ...

But I think your problem may be that the Cygwin dlls need to be on the 
search path,
and you're hoping that none of them have names that are the same as 
ones earlier on

the path ...

Best - Eliot Moss
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


I did try copying all of the .dll files in the Cygwin bin folder to the 
same folder where the copy of Cygwin's tar.exe sits.  That folder 
appears first in the PATH.  But despite that, trying to invoke tar from 
the cmd window still pops up the window saying cyggcc_s-1.dll can't be 
found.


Regards,

Doug Coup

Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Using cygwin tar from a DOS window

[Eliot Moss]

On 9/2/2020 1:00 PM, Douglas Coup wrote:


On 9/2/2020 12:53 PM, Bill Stewart wrote:

On Wed, Sep 2, 2020 at 8:58 AM Douglas Coup wrote:

But if I use tar from a DOS window ...
Surely you don't mean DOS? DOS doesn't exist in Windows any more (unless
you are using an emulator like DosBox or a VM).

Do you mean a cmd.exe console window? (cmd.exe is a Windows console-mode
program that, despite appearances, is not "DOS." DOS was a real-mode
single-tasking operating system.)

Bill
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:    https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Yes, a cmd.exe console window.


Hardly the point :-) ...

But I think your problem may be that the Cygwin dlls need to be on the search 
path,
and you're hoping that none of them have names that are the same as ones 
earlier on
the path ...

Best - Eliot Moss
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Using cygwin tar from a DOS window

[Douglas Coup]

On 9/2/2020 12:53 PM, Bill Stewart wrote:

On Wed, Sep 2, 2020 at 8:58 AM Douglas Coup wrote:

But if I use tar from a DOS window ...
Surely you don't mean DOS? DOS doesn't exist in Windows any more (unless
you are using an emulator like DosBox or a VM).

Do you mean a cmd.exe console window? (cmd.exe is a Windows console-mode
program that, despite appearances, is not "DOS." DOS was a real-mode
single-tasking operating system.)

Bill
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple


Yes, a cmd.exe console window.

Regards,

Doug Coup

Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Using cygwin tar from a DOS window

[Bill Stewart]

On Wed, Sep 2, 2020 at 8:58 AM Douglas Coup wrote:

But if I use tar from a DOS window ...
>

Surely you don't mean DOS? DOS doesn't exist in Windows any more (unless
you are using an emulator like DosBox or a VM).

Do you mean a cmd.exe console window? (cmd.exe is a Windows console-mode
program that, despite appearances, is not "DOS." DOS was a real-mode
single-tasking operating system.)

Bill
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Corinna Vinschen]

Hi Takashi,

On Sep  3 01:25, Takashi Yano via Cygwin-patches wrote:
> Hi Corinna,
> 
> On Wed, 2 Sep 2020 17:24:50 +0200
> Corinna Vinschen  wrote:
> > > > get_locale_from_env() and get_langinfo() should go away.  If we just
> > > > need a codepage for get_ttyp ()->term_code_page, we should really find a
> > > > way to do this from within internal_setlocale().
> > > 
> > > I looked into internal_setlocale() code, but I could not found
> > > the code which handles thecode page. I found the code handling
> > > the code page in __set_charset_from_locale() function in nlsfuncs.cc,
> > > but it does not return code page itself. Could you please explain
> > > more detail of your idea?
> > 
> > I had none yet :)  I was just musing, without actually thinking about a
> > solution.  But I think this isn't very complicated.  Given this is
> > inside Cygwin, nothing keeps the function to have a well-defined
> > side-effect, as in setting a (not yet existing) member "term_code_page"
> > of cygheap->locale.
> > 
> > Kind of like this:
> > [...]
> I have tried your code, however, it does not work as expected.
> It seems that __set_charset_from_locale() is not called.
> cygheap->locale.term_code_page is always 0.

Ah, right!  Take a look into newlib/libc/locale/locale.c, function
__loadlocale().  This function is called from _setlocale_r().  However,
it calls __set_charset_from_locale() *only* if the charset isn't already
given explicitely in the LC_* or LANG string, because otherwise we
already know the charset, after all.

Darn!  That foils my plans for world domination...

> Let me consider a while.

Thanks, I'll do the same.  I'd really like to simplify this stuff
and doing the locale shuffle in two entirely different locations
at different times is prone to getting out of sync.


Corinna

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Takashi Yano via Cygwin-patches]

Hi Corinna,

On Wed, 2 Sep 2020 17:24:50 +0200
Corinna Vinschen  wrote:
> On Sep  2 19:54, Takashi Yano via Cygwin-patches wrote:
> > Hi Corinna,
> > 
> > On Wed, 2 Sep 2020 10:38:18 +0200
> > Corinna Vinschen wrote:
> > > On Sep  2 10:30, Corinna Vinschen wrote:
> > > > Ok guys, I'm not opposed to this change in terms of its result,
> > > > but I'm starting to wonder why all this locale code in fhandler_tty
> > > > is necessary at all.
> > > > 
> > > > I see that get_langinfo() calls __loadlocale and performs a lot of stuff
> > > > on the charsets which looks like duplicates of the initial_setlocale()
> > > > call performed at DLL startup.
> > > > 
> > > > If there's anything missing in the initial_setlocale() call which would
> > > > be required by the pseudo tty code?  What exactly is it?  The codepage?
> > > > And why can't we just add the info to cygheap->locale at 
> > > > initial_setlocale()
> > > > time so it's available at exec time without going through all this 
> > > > hassle
> > > > every time?
> > > > 
> > > > Apart from that, all this locale/charset/lcid stuff should be 
> > > > concentrated
> > > > in nlsfunc.cc ideally.
> > > 
> > > get_locale_from_env() and get_langinfo() should go away.  If we just
> > > need a codepage for get_ttyp ()->term_code_page, we should really find a
> > > way to do this from within internal_setlocale().
> > 
> > I looked into internal_setlocale() code, but I could not found
> > the code which handles thecode page. I found the code handling
> > the code page in __set_charset_from_locale() function in nlsfuncs.cc,
> > but it does not return code page itself. Could you please explain
> > more detail of your idea?
> 
> I had none yet :)  I was just musing, without actually thinking about a
> solution.  But I think this isn't very complicated.  Given this is
> inside Cygwin, nothing keeps the function to have a well-defined
> side-effect, as in setting a (not yet existing) member "term_code_page"
> of cygheap->locale.
> 
> Kind of like this:
> 
> diff --git a/winsup/cygwin/cygheap.h b/winsup/cygwin/cygheap.h
> index 8877cc358c39..2b84f4252071 100644
> --- a/winsup/cygwin/cygheap.h
> +++ b/winsup/cygwin/cygheap.h
> @@ -341,6 +341,7 @@ struct cygheap_debug
>  struct cygheap_locale
>  {
>mbtowc_p mbtowc;
> +  UINT term_code_page;
>  };
>  
>  struct user_heap_info
> diff --git a/winsup/cygwin/nlsfuncs.cc b/winsup/cygwin/nlsfuncs.cc
> index 668d7eb9e778..752f4239d911 100644
> --- a/winsup/cygwin/nlsfuncs.cc
> +++ b/winsup/cygwin/nlsfuncs.cc
> @@ -1298,6 +1298,9 @@ __set_charset_from_locale (const char *locale, char 
> *charset)
>   LOCALE_IDEFAULTANSICODEPAGE | LOCALE_RETURN_NUMBER,
>   (PWCHAR) , sizeof cp))
>  cp = 0;
> +  /* Store codepage in cygheap->locale so fhandler_tty can switch the
> + pseudo console to the correct codepage. */
> +  cygheap->locale.term_code_page = cp ?: CP_UTF8;
>/* Translate codepage and lcid to a charset closely aligned with the 
> default
>   charsets defined in Glibc. */
>const char *cs;
> 
> Make sense?

I have tried your code, however, it does not work as expected.
It seems that __set_charset_from_locale() is not called.
cygheap->locale.term_code_page is always 0.

I have added following lines into setup_locale() to make sure
to call __set_charset_from_locale() for a test,

  setlocale (LC_ALL, "");
  __set_charset_from_locale (__get_global_locale()->categories[LC_CTYPE], 
charset);
  get_ttyp ()->term_code_page = cygheap->locale.term_code_page;

however, term_code_page is set to 932 if locale is ja_JP.UTF-8.
In this case term_code_page should be CP_UTF8 (65001).

The code page retrieved in __set_charset_from_locale() is not
based on "UTF-8" but "ja_JP".

Let me consider a while.

-- 
Takashi Yano 

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Corinna Vinschen]

On Sep  2 17:24, Corinna Vinschen wrote:
> On Sep  2 19:54, Takashi Yano via Cygwin-patches wrote:
> > Hi Corinna,
> > 
> > On Wed, 2 Sep 2020 10:38:18 +0200
> > Corinna Vinschen wrote:
> > > On Sep  2 10:30, Corinna Vinschen wrote:
> > > > Ok guys, I'm not opposed to this change in terms of its result,
> > > > but I'm starting to wonder why all this locale code in fhandler_tty
> > > > is necessary at all.
> > > > 
> > > > I see that get_langinfo() calls __loadlocale and performs a lot of stuff
> > > > on the charsets which looks like duplicates of the initial_setlocale()
> > > > call performed at DLL startup.
> > > > 
> > > > If there's anything missing in the initial_setlocale() call which would
> > > > be required by the pseudo tty code?  What exactly is it?  The codepage?
> > > > And why can't we just add the info to cygheap->locale at 
> > > > initial_setlocale()
> > > > time so it's available at exec time without going through all this 
> > > > hassle
> > > > every time?
> > > > 
> > > > Apart from that, all this locale/charset/lcid stuff should be 
> > > > concentrated
> > > > in nlsfunc.cc ideally.
> > > 
> > > get_locale_from_env() and get_langinfo() should go away.  If we just
> > > need a codepage for get_ttyp ()->term_code_page, we should really find a
> > > way to do this from within internal_setlocale().
> > 
> > I looked into internal_setlocale() code, but I could not found
> > the code which handles thecode page. I found the code handling
> > the code page in __set_charset_from_locale() function in nlsfuncs.cc,
> > but it does not return code page itself. Could you please explain
> > more detail of your idea?
> 
> I had none yet :)  I was just musing, without actually thinking about a
> solution.  But I think this isn't very complicated.  Given this is
> inside Cygwin, nothing keeps the function to have a well-defined
> side-effect, as in setting a (not yet existing) member "term_code_page"
> of cygheap->locale.
> 
> Kind of like this:

Actually, this is a bit too simple, but you get the idea.  We need to
align the terminal codepage with the actual Cygwin charset, along the
lines of what your setup_locale is doing standalone yet.  Except in case
of ASCII, where we default to UTF-8 internally.  The important part here
is that we do this once, and that we don't have unnecessary code
duplication.


Corinna

Re: [ITP] python-getdevinfo

[Hamish McIntyre-Bhatty via Cygwin-apps]

*bump* in case this has not been seen.

Hamish

On 26/08/2020 10:35, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> Okay, I have updated the packages (same location:
> https://www.hamishmb.com/files/cygwin-temp/). It should now handle fork
> errors better.
>
> If it fails again, please post the full output from the test command so
> I can see what version(s) of Python the tests are failing on. It might
> be useful for someone else to have a go as well - would be good to know
> multiple people can reproduce this issue as I have still had no luck
> doing that.
>
> Thanks for your patience,
>
> Hamish
>
> On 21/08/2020 16:33, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
>> On 20/08/2020 07:01, Marco Atzeri via Cygwin-apps wrote:
>>> On 19.08.2020 13:22, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
 On 19/08/2020 06:53, Marco Atzeri via Cygwin-apps wrote:
> something looks wrong on test
>
> ==
> ERROR: test_get_info (tests.getdevinfo_tests_cygwin.TestGetInfo)
> Test that the information can be collected on this system without error
> --
> Traceback (most recent call last):
>    File
> "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/src/getdevinfo-1.1.0/getdevinfo/tests/getdevinfo_tests_cygwin.py",
>
> line 218, in test_get_info
>  cygwin.get_info()
>    File
> "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/build/getdevinfo/cygwin.py",
>
> line 101, in get_info
>  get_device_info(disk)
>    File
> "/pub/tmp/python-getdevinfo-1.1.0-1.src/python-getdevinfo-1.1.0-1.x86_64/build/getdevinfo/cygwin.py",
>
> line 135, in get_device_info
>  cmd = subprocess.run([SMARTCTL, "-i", host_disk, "-j"],
> stdout=subprocess.PIPE,
>    File "/usr/lib/python3.8/subprocess.py", line 489, in run
>  with Popen(*popenargs, **kwargs) as process:
>    File "/usr/lib/python3.8/subprocess.py", line 854, in __init__
>  self._execute_child(args, executable, preexec_fn, close_fds,
>    File "/usr/lib/python3.8/subprocess.py", line 1637, in
> _execute_child
>  self.pid = _posixsubprocess.fork_exec(
> BlockingIOError: [Errno 11] Resource temporarily unavailable
>
> --
> Ran 23 tests in 0.679s
>
> FAILED (errors=1)
> NOTE: These tests won't work correctly without administrator
> privileges.
>
> $ id
> uid=197609(Marco) gid=544(Administratoren)
> groups=544(Administratoren),197121(Kein)
 Unfortunately I have not been able to reproduce this issue on my end
 with either 32-bit or 64-bit Cygwin. What happens when you run
 "/usr/sbin/smartctl.exe -i /dev/sda -j" (assuming /dev/sda is a disk
 that Cygwin sees)? Note that the output may include the drive serial
 number - make sure to blank it out if you post the output here.

 If this is on 32-bit Cygwin, this looks like the good old fork bug to
 me, seeing as you're getting "11 Resource temporarily unavailable" when
 attempting to fork. I can't remember what worked to fix that for me the
 last time I had it, might have been antivirus software exceptions. I
 would say that maybe some packages need updating, but given you've been
 releasing packages in the last few days, I highly doubt your Cygwin
 install is out of date.

 If the smartctl command works, could you try running the tests again
 please?

 Hamish

>>> /usr/sbin/smartctl.exe -i /dev/sda -j
>>>
>>> {
>>>   "json_format_version": [
>>>     1,
>>>     0
>>>   ],
>>>   "smartctl": {
>>>     "version": [
>>>   7,
>>>   1
>>>     ],
>>>     "svn_revision": "5022",
>>>     "platform_info": "x86_64-pc-cygwin-w10-b19041",
>>>     "build_info": "(cygwin-7.1-1)",
>>>     "argv": [
>>>   "smartctl",
>>>   "-i",
>>>   "/dev/sda",
>>>   "-j"
>>>     ],
>>>     "exit_status": 0
>>>   },
>>>   "device": {
>>>     "name": "/dev/sda",
>>>     "info_name": "/dev/sda",
>>>     "type": "ata",
>>>     "protocol": "ATA"
>>>   },
>>>   "model_family": "Seagate Mobile HDD",
>>>   "model_name": "ST1000LM035-1RK172",
>>>   "serial_number": "WL10S143",
>>>   "wwn": {
>>>     "naa": 5,
>>>     "oui": 3152,
>>>     "id": 2907615223
>>>   },
>>>   "firmware_version": "RSM7",
>>>   "user_capacity": {
>>>     "blocks": 1953525168,
>>>     "bytes": 1000204886016
>>>   },
>>>   "logical_block_size": 512,
>>>   "physical_block_size": 4096,
>>>   "rotation_rate": 5400,
>>>   "form_factor": {
>>>     "ata_value": 3,
>>>     "name": "2.5 inches"
>>>   },
>>>   "in_smartctl_database": true,
>>>   "ata_version": {
>>>     "string": "ACS-3 T13/2161-D revision 3b",
>>>     "major_value": 2032,
>>>     "minor_value": 31
>>>   },
>>>   

Re: Mintty text glitches when using up key

[Hamish McIntyre-Bhatty via Cygwin]

On 28/08/2020 17:45, Thomas Wolff wrote:
> Am 28.08.2020 um 17:48 schrieb Hamish McIntyre-Bhatty via Cygwin:
>> On 28/08/2020 16:13, Thomas Wolff wrote:
>>> Am 28.08.2020 um 16:31 schrieb Hamish McIntyre-Bhatty via Cygwin:
 My apologies. I mean when a the command with its arguments are long
 enough to wrap around the width of the Mintty window.
>>> That works fine normally but fails under certain additional
>>> conditions. Please provide a reproducible test case in order to get
>>> suitable comments. Also, which shell do you use?
>>> Thomas
>> Okay, I'll see if I can come up with a test case.
>>
>> If I can, would it be better for me to file a bug on GitHub for this
>> as well?
> Likely not as I firmly believe it's not a terminal issue.

I suspect you are correct. After trying to cause the problem in a few
different ways, I have not been able to do so. I guess it's either not a
bug at all, or it occurs so rarely/in such a small corner case that it's
very hard to pin down.

Apologies for the noise, and thank you all for your hard work on Cygwin.

Hamish



0x87B761FE07F548D6.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Corinna Vinschen]

On Sep  2 19:54, Takashi Yano via Cygwin-patches wrote:
> Hi Corinna,
> 
> On Wed, 2 Sep 2020 10:38:18 +0200
> Corinna Vinschen wrote:
> > On Sep  2 10:30, Corinna Vinschen wrote:
> > > Ok guys, I'm not opposed to this change in terms of its result,
> > > but I'm starting to wonder why all this locale code in fhandler_tty
> > > is necessary at all.
> > > 
> > > I see that get_langinfo() calls __loadlocale and performs a lot of stuff
> > > on the charsets which looks like duplicates of the initial_setlocale()
> > > call performed at DLL startup.
> > > 
> > > If there's anything missing in the initial_setlocale() call which would
> > > be required by the pseudo tty code?  What exactly is it?  The codepage?
> > > And why can't we just add the info to cygheap->locale at 
> > > initial_setlocale()
> > > time so it's available at exec time without going through all this hassle
> > > every time?
> > > 
> > > Apart from that, all this locale/charset/lcid stuff should be concentrated
> > > in nlsfunc.cc ideally.
> > 
> > get_locale_from_env() and get_langinfo() should go away.  If we just
> > need a codepage for get_ttyp ()->term_code_page, we should really find a
> > way to do this from within internal_setlocale().
> 
> I looked into internal_setlocale() code, but I could not found
> the code which handles thecode page. I found the code handling
> the code page in __set_charset_from_locale() function in nlsfuncs.cc,
> but it does not return code page itself. Could you please explain
> more detail of your idea?

I had none yet :)  I was just musing, without actually thinking about a
solution.  But I think this isn't very complicated.  Given this is
inside Cygwin, nothing keeps the function to have a well-defined
side-effect, as in setting a (not yet existing) member "term_code_page"
of cygheap->locale.

Kind of like this:

diff --git a/winsup/cygwin/cygheap.h b/winsup/cygwin/cygheap.h
index 8877cc358c39..2b84f4252071 100644
--- a/winsup/cygwin/cygheap.h
+++ b/winsup/cygwin/cygheap.h
@@ -341,6 +341,7 @@ struct cygheap_debug
 struct cygheap_locale
 {
   mbtowc_p mbtowc;
+  UINT term_code_page;
 };
 
 struct user_heap_info
diff --git a/winsup/cygwin/nlsfuncs.cc b/winsup/cygwin/nlsfuncs.cc
index 668d7eb9e778..752f4239d911 100644
--- a/winsup/cygwin/nlsfuncs.cc
+++ b/winsup/cygwin/nlsfuncs.cc
@@ -1298,6 +1298,9 @@ __set_charset_from_locale (const char *locale, char 
*charset)
LOCALE_IDEFAULTANSICODEPAGE | LOCALE_RETURN_NUMBER,
(PWCHAR) , sizeof cp))
 cp = 0;
+  /* Store codepage in cygheap->locale so fhandler_tty can switch the
+ pseudo console to the correct codepage. */
+  cygheap->locale.term_code_page = cp ?: CP_UTF8;
   /* Translate codepage and lcid to a charset closely aligned with the default
  charsets defined in Glibc. */
   const char *cs;

Make sense?


Thanks,
Corinna

Using cygwin tar from a DOS window

[Douglas Coup]

Hello Cygwin community.

I've recently started using a new Windows 10 workstation, on which I've 
installed 64-bit Cygwin, including tar v1.29.


Windows 10 has its own tar.exe, but I need the Cygwin tar to be found 
regardless of whether I'm using a Cygwin command window or a DOS command 
window.  Since from a DOS window I want Windows .exe files to be found 
for all situations except tar, I've copied the Cygwin tar.exe to a 
folder of its own and placed that folder in the PATH at the beginning to 
make sure Cygwin's tar.exe is found before the Windows tar.exe.


If I use tar from a Cygwin window, it works.  The tar.exe is found in 
Cygwin's own /usr/bin directory.


But if I use tar from a DOS window, I get a pop-up window that says the 
program can't start because cyggcc_s-1.dll can't be found.  This DLL is 
not present in the Cygwin hierarchy.  What's strange is if I run 
"cygcheck tar" from a Cygwin window, that DLL is not listed as a dependency.


This configuration worked successfully on my previous Windows 10 
workstation, where I had 32-bit Cygwin installed, including tar v1.27.


Any thoughts?  I'm wondering if I need to downgrade to tar v1.27 on my 
new workstation.


Regards,

Douglas Coup

--
Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Takashi Yano via Cygwin-patches]

On Wed, 2 Sep 2020 11:12:53 +0200 (CEST)
Johannes Schindelin wrote:
> On Wed, 2 Sep 2020, Takashi Yano wrote:
> > OK, I will check Angular/CLI next. But I am not familier with
> > Agnular/CLI. Could you please provide simple steps to reproduce
> > the problem?
> 
> Here is a report: https://github.com/git-for-windows/git/issues/2793

I already read that thread, and I have try following step.

1) Install node.js
2) npm install --global @angular/cli
3) ng new test-app
4) cd test-app
5) ng test --code-coverage

However, the output is very differnt from the bug report,
and there seems to be no garbled output.

The output is something like:

Compiling @angular/core : es2015 as esm2015
Compiling @angular/animations : es2015 as esm2015
Compiling @angular/compiler/testing : es2015 as esm2015
Compiling @angular/common : es2015 as esm2015
Compiling @angular/animations/browser : es2015 as esm2015
Compiling @angular/core/testing : es2015 as esm2015
Compiling @angular/animations/browser/testing : es2015 as esm2015
Compiling @angular/platform-browser : es2015 as esm2015
Compiling @angular/common/http : es2015 as esm2015
Compiling @angular/common/testing : es2015 as esm2015
Compiling @angular/router : es2015 as esm2015
Compiling @angular/forms : es2015 as esm2015
Compiling @angular/platform-browser-dynamic : es2015 as esm2015
Compiling @angular/platform-browser/testing : es2015 as esm2015
Compiling @angular/platform-browser/animations : es2015 as esm2015
Compiling @angular/common/http/testing : es2015 as esm2015
Compiling @angular/platform-browser-dynamic/testing : es2015 as esm2015
Compiling @angular/router/testing : es2015 as esm2015
10% building 2/2 modules 0 active02 09 2020 23:49:25.110:WARN [karma]: No captur
ed browser, open http://localhost:9876/
02 09 2020 23:49:25.118:INFO [karma-server]: Karma v5.0.9 server started at http
://0.0.0.0:9876/
02 09 2020 23:49:25.119:INFO [launcher]: Launching browsers Chrome with concurre
ncy unlimited
02 09 2020 23:49:25.125:INFO [launcher]: Starting browser Chrome
92% additional asset processing copy-webpack-plugin02 09 2020 23:49:34.003:WARN
[karma]: No captured browser, open http://localhost:9876/
02 09 2020 23:49:34.907:INFO [Chrome 85.0.4183.83 (Windows 10)]: Connected on so
cket z7khH23JfW4v-_Tt with id 59608191
Chrome 85.0.4183.83 (Windows 10): Executed 3 of 3 SUCCESS (0.62 secs / 0.273 sec
s)
TOTAL: 3 SUCCESS
TOTAL: 3 SUCCESS
TOTAL: 3 SUCCESS

=== Coverage summary ===
Statements   : 100% ( 6/6 )
Branches : 100% ( 0/0 )
Functions: 100% ( 0/0 )
Lines: 100% ( 5/5 )


What's wrong?

> But why do you want to look into Angular/CLI? Do you really think that it
> makes sense to try to fix every console app out there? Really? Wouldn't it
> make more sense to just accept that there are many console applications
> that are broken by the recent change, and accommodate them in the Cygwin
> runtime? That would take substantially less time.

It is important to know what's happning actually to fix the issue.
Superficial patch makes the problem more complicated.

-- 
Takashi Yano 

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Johannes Schindelin]

Hi Takashi,


On Wed, 2 Sep 2020, Takashi Yano wrote:

> On Wed, 2 Sep 2020 08:26:04 +0200 (CEST)
> Johannes Schindelin wrote:
> > Hi Takashi,
> >
> > On Wed, 2 Sep 2020, Takashi Yano via Cygwin-patches wrote:
> >
> > > On Wed, 2 Sep 2020 10:30:14 +0200
> > > Corinna Vinschen wrote:
> > > > On Sep  1 18:19, Johannes Schindelin wrote:
> > > > > When `LANG=en_US.UTF-8`, the detected `LCID` is 0x0409, which is
> > > > > correct, but after that (at least if Pseudo Console support is 
> > > > > enabled),
> > > > > we try to find the default code page for that `LCID`, which is ASCII
> > > > > (437). Subsequently, we set the Console output code page to that 
> > > > > value,
> > > > > completely ignoring that we wanted to use UTF-8.
> > > > >
> > > > > Let's not ignore the specifically asked-for UTF-8 character set.
> > > > >
> > > > > While at it, let's also set the Console output code page even if 
> > > > > Pseudo
> > > > > Console support is disabled; contrary to the behavior of v3.0.7, the
> > > > > Console output code page is not ignored in that case.
> > > > >
> > > > > The most common symptom would be that console applications which do 
> > > > > not
> > > > > specifically call `SetConsoleOutputCP()` but output UTF-8-encoded text
> > > > > seem to be broken with v3.1.x when they worked plenty fine with 
> > > > > v3.0.x.
> > > > >
> > > > > This fixes https://github.com/msys2/MSYS2-packages/issues/1974,
> > > > > https://github.com/msys2/MSYS2-packages/issues/2012,
> > > > > https://github.com/rust-lang/cargo/issues/8369,
> > > > > https://github.com/git-for-windows/git/issues/2734,
> > > > > https://github.com/git-for-windows/git/issues/2793,
> > > > > https://github.com/git-for-windows/git/issues/2792, and possibly 
> > > > > quite a
> > > > > few others.
> > > > >
> > > > > Signed-off-by: Johannes Schindelin 
> > > > > ---
> > > > >  winsup/cygwin/fhandler_tty.cc | 9 +
> > > > >  1 file changed, 9 insertions(+)
> > > >
> > > > Ok guys, I'm not opposed to this change in terms of its result,
> > >
> > > I am sorry, but I cannot agree with Johannes's patch.
> > >
> > > For example, code page in Japan is CP932 by default.
> > > In this case, cmd.exe, netsh.exe and so on are generate
> > > messages in Japanese.
> > >
> > > If the code page is set to CP_UTF8, messages from such
> > > commands changes to english. I guess similar things happen
> > > for other locales.
> > >
> > > I do not prefer this result.
> > >
> > > Furthermore, I looked into the issue:
> > > https://github.com/git-for-windows/git/issues/2734
> > > and I found that git-for-windows always use utf-8
> > > encoding even if the locale is ja_JP.CP932.
> > > It does not change coding based on locale or code
> > > page.
> > >
> > > Even with Johannes's patch, if mintty is started with
> > > locale ja_JP.CP932, the file name will be garbled
> > > bacause SetConsoleOutputCP(CP_UTF8) will not be called.
> > >
> > > IMHO, it is the problem of git-for-windows rather
> > > than cygwin and msys2.
> > >
> > > To make current version of git-for-windows work, it is
> > > necessary to set code page to CP_UTF8 regardless locale.
> > > This does not make sense at all.
> >
> > You are misrepresenting the problem. It has nothing to do with Git for
> > Windows. For example, if you run tests in an Angular project inside
> > Cygwin's MinTTY, the output will be garbled because node.js (or the
> > Angular libraries, I don't know) will interpret `LANG` or something.
>
> You listed these issues in git-for-windows:
> > > > > https://github.com/git-for-windows/git/issues/2734,
> > > > > https://github.com/git-for-windows/git/issues/2792,
> didn't you? Therefore, I looked into them.
>
> OK, I will check Angular/CLI next. But I am not familier with
> Agnular/CLI. Could you please provide simple steps to reproduce
> the problem?

Here is a report: https://github.com/git-for-windows/git/issues/2793

But why do you want to look into Angular/CLI? Do you really think that it
makes sense to try to fix every console app out there? Really? Wouldn't it
make more sense to just accept that there are many console applications
that are broken by the recent change, and accommodate them in the Cygwin
runtime? That would take substantially less time.

Ciao,
Johannes

>
> > This is a much bigger problem than you make it sound. The console
> > applications that do _not_ call `SetConsoleOutputCP()` are so
> > ubiquituous. I think you are underestimating that problem rather
> > dramatically.
> >
> > Ciao,
> > Johannes
>
>
> --
> Takashi Yano 
>

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Takashi Yano via Cygwin-patches]

On Wed, 2 Sep 2020 08:26:04 +0200 (CEST)
Johannes Schindelin wrote:
> Hi Takashi,
> 
> On Wed, 2 Sep 2020, Takashi Yano via Cygwin-patches wrote:
> 
> > On Wed, 2 Sep 2020 10:30:14 +0200
> > Corinna Vinschen wrote:
> > > On Sep  1 18:19, Johannes Schindelin wrote:
> > > > When `LANG=en_US.UTF-8`, the detected `LCID` is 0x0409, which is
> > > > correct, but after that (at least if Pseudo Console support is enabled),
> > > > we try to find the default code page for that `LCID`, which is ASCII
> > > > (437). Subsequently, we set the Console output code page to that value,
> > > > completely ignoring that we wanted to use UTF-8.
> > > >
> > > > Let's not ignore the specifically asked-for UTF-8 character set.
> > > >
> > > > While at it, let's also set the Console output code page even if Pseudo
> > > > Console support is disabled; contrary to the behavior of v3.0.7, the
> > > > Console output code page is not ignored in that case.
> > > >
> > > > The most common symptom would be that console applications which do not
> > > > specifically call `SetConsoleOutputCP()` but output UTF-8-encoded text
> > > > seem to be broken with v3.1.x when they worked plenty fine with v3.0.x.
> > > >
> > > > This fixes https://github.com/msys2/MSYS2-packages/issues/1974,
> > > > https://github.com/msys2/MSYS2-packages/issues/2012,
> > > > https://github.com/rust-lang/cargo/issues/8369,
> > > > https://github.com/git-for-windows/git/issues/2734,
> > > > https://github.com/git-for-windows/git/issues/2793,
> > > > https://github.com/git-for-windows/git/issues/2792, and possibly quite a
> > > > few others.
> > > >
> > > > Signed-off-by: Johannes Schindelin 
> > > > ---
> > > >  winsup/cygwin/fhandler_tty.cc | 9 +
> > > >  1 file changed, 9 insertions(+)
> > >
> > > Ok guys, I'm not opposed to this change in terms of its result,
> >
> > I am sorry, but I cannot agree with Johannes's patch.
> >
> > For example, code page in Japan is CP932 by default.
> > In this case, cmd.exe, netsh.exe and so on are generate
> > messages in Japanese.
> >
> > If the code page is set to CP_UTF8, messages from such
> > commands changes to english. I guess similar things happen
> > for other locales.
> >
> > I do not prefer this result.
> >
> > Furthermore, I looked into the issue:
> > https://github.com/git-for-windows/git/issues/2734
> > and I found that git-for-windows always use utf-8
> > encoding even if the locale is ja_JP.CP932.
> > It does not change coding based on locale or code
> > page.
> >
> > Even with Johannes's patch, if mintty is started with
> > locale ja_JP.CP932, the file name will be garbled
> > bacause SetConsoleOutputCP(CP_UTF8) will not be called.
> >
> > IMHO, it is the problem of git-for-windows rather
> > than cygwin and msys2.
> >
> > To make current version of git-for-windows work, it is
> > necessary to set code page to CP_UTF8 regardless locale.
> > This does not make sense at all.
> 
> You are misrepresenting the problem. It has nothing to do with Git for
> Windows. For example, if you run tests in an Angular project inside
> Cygwin's MinTTY, the output will be garbled because node.js (or the
> Angular libraries, I don't know) will interpret `LANG` or something.

You listed these issues in git-for-windows:
> > > > https://github.com/git-for-windows/git/issues/2734,
> > > > https://github.com/git-for-windows/git/issues/2792,
didn't you? Therefore, I looked into them.

OK, I will check Angular/CLI next. But I am not familier with
Agnular/CLI. Could you please provide simple steps to reproduce
the problem?

> This is a much bigger problem than you make it sound. The console
> applications that do _not_ call `SetConsoleOutputCP()` are so
> ubiquituous. I think you are underestimating that problem rather
> dramatically.
> 
> Ciao,
> Johannes


-- 
Takashi Yano 

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Johannes Schindelin]

Hi Takashi,

On Wed, 2 Sep 2020, Takashi Yano via Cygwin-patches wrote:

> On Wed, 2 Sep 2020 10:30:14 +0200
> Corinna Vinschen wrote:
> > On Sep  1 18:19, Johannes Schindelin wrote:
> > > When `LANG=en_US.UTF-8`, the detected `LCID` is 0x0409, which is
> > > correct, but after that (at least if Pseudo Console support is enabled),
> > > we try to find the default code page for that `LCID`, which is ASCII
> > > (437). Subsequently, we set the Console output code page to that value,
> > > completely ignoring that we wanted to use UTF-8.
> > >
> > > Let's not ignore the specifically asked-for UTF-8 character set.
> > >
> > > While at it, let's also set the Console output code page even if Pseudo
> > > Console support is disabled; contrary to the behavior of v3.0.7, the
> > > Console output code page is not ignored in that case.
> > >
> > > The most common symptom would be that console applications which do not
> > > specifically call `SetConsoleOutputCP()` but output UTF-8-encoded text
> > > seem to be broken with v3.1.x when they worked plenty fine with v3.0.x.
> > >
> > > This fixes https://github.com/msys2/MSYS2-packages/issues/1974,
> > > https://github.com/msys2/MSYS2-packages/issues/2012,
> > > https://github.com/rust-lang/cargo/issues/8369,
> > > https://github.com/git-for-windows/git/issues/2734,
> > > https://github.com/git-for-windows/git/issues/2793,
> > > https://github.com/git-for-windows/git/issues/2792, and possibly quite a
> > > few others.
> > >
> > > Signed-off-by: Johannes Schindelin 
> > > ---
> > >  winsup/cygwin/fhandler_tty.cc | 9 +
> > >  1 file changed, 9 insertions(+)
> >
> > Ok guys, I'm not opposed to this change in terms of its result,
>
> I am sorry, but I cannot agree with Johannes's patch.
>
> For example, code page in Japan is CP932 by default.
> In this case, cmd.exe, netsh.exe and so on are generate
> messages in Japanese.
>
> If the code page is set to CP_UTF8, messages from such
> commands changes to english. I guess similar things happen
> for other locales.
>
> I do not prefer this result.
>
> Furthermore, I looked into the issue:
> https://github.com/git-for-windows/git/issues/2734
> and I found that git-for-windows always use utf-8
> encoding even if the locale is ja_JP.CP932.
> It does not change coding based on locale or code
> page.
>
> Even with Johannes's patch, if mintty is started with
> locale ja_JP.CP932, the file name will be garbled
> bacause SetConsoleOutputCP(CP_UTF8) will not be called.
>
> IMHO, it is the problem of git-for-windows rather
> than cygwin and msys2.
>
> To make current version of git-for-windows work, it is
> necessary to set code page to CP_UTF8 regardless locale.
> This does not make sense at all.

You are misrepresenting the problem. It has nothing to do with Git for
Windows. For example, if you run tests in an Angular project inside
Cygwin's MinTTY, the output will be garbled because node.js (or the
Angular libraries, I don't know) will interpret `LANG` or something.

This is a much bigger problem than you make it sound. The console
applications that do _not_ call `SetConsoleOutputCP()` are so
ubiquituous. I think you are underestimating that problem rather
dramatically.

Ciao,
Johannes

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Johannes Schindelin]

Hi,

On Tue, 1 Sep 2020, Johannes Schindelin wrote:

> When `LANG=en_US.UTF-8`, the detected `LCID` is 0x0409, which is
> correct, but after that (at least if Pseudo Console support is enabled),
> we try to find the default code page for that `LCID`, which is ASCII
> (437). Subsequently, we set the Console output code page to that value,
> completely ignoring that we wanted to use UTF-8.
>
> Let's not ignore the specifically asked-for UTF-8 character set.
>
> While at it, let's also set the Console output code page even if Pseudo
> Console support is disabled; contrary to the behavior of v3.0.7, the
> Console output code page is not ignored in that case.
>
> The most common symptom would be that console applications which do not
> specifically call `SetConsoleOutputCP()` but output UTF-8-encoded text
> seem to be broken with v3.1.x when they worked plenty fine with v3.0.x.
>
> This fixes https://github.com/msys2/MSYS2-packages/issues/1974,
> https://github.com/msys2/MSYS2-packages/issues/2012,
> https://github.com/rust-lang/cargo/issues/8369,
> https://github.com/git-for-windows/git/issues/2734,
> https://github.com/git-for-windows/git/issues/2793,
> https://github.com/git-for-windows/git/issues/2792, and possibly quite a
> few others.
>
> Signed-off-by: Johannes Schindelin 
> ---
>  winsup/cygwin/fhandler_tty.cc | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
> index 06789a500..414c26992 100644
> --- a/winsup/cygwin/fhandler_tty.cc
> +++ b/winsup/cygwin/fhandler_tty.cc
> @@ -2859,6 +2859,15 @@ fhandler_pty_slave::setup_locale (void)
>char charset[ENCODING_LEN + 1] = "ASCII";
>LCID lcid = get_langinfo (locale, charset);
>
> +  /* Special-case the UTF-8 character set */
> +  if (strcasecmp (charset, "UTF-8") == 0)
> +{
> +  get_ttyp ()->term_code_page = CP_UTF8;
> +  SetConsoleCP (CP_UTF8);
> +  SetConsoleOutputCP (CP_UTF8);
> +  return;
> +}
> +

Just a word of warning: while this patch can be ported to a634adda5
(libm/machine/arm: Rename s*_fma.c -> s*_fma_arm.c, 2020-09-01) relatively
easily (and the first two patches of this patch series cannot, as they are
no longer applicable after the complete redesign of the Pseudo Console
support), it only works as intended in the `disable_pcon` mode.

The new design calls for Pseudo Consoles to be created per spawned console
application.

And I have not found any way to convince my local version of the runtime
to change the code page of these Pseudo Consoles away from the rather
unfortunate default 437.

This is a problem.

Take for example https://github.com/git-for-windows/git/issues/2793.
Telling the users that they should patch node.js and recompile is probably
not going to fly.

Hopefully there is a way to fix this, otherwise Pseudo Console support
will continue to be quite the support burden.

Ciao,
Johannes

>/* Set console code page from locale */
>if (get_pseudo_console ())
>  {
> --
> 2.27.0
>
>

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Takashi Yano via Cygwin-patches]

Hi Corinna,

On Wed, 2 Sep 2020 10:38:18 +0200
Corinna Vinschen wrote:
> On Sep  2 10:30, Corinna Vinschen wrote:
> > Ok guys, I'm not opposed to this change in terms of its result,
> > but I'm starting to wonder why all this locale code in fhandler_tty
> > is necessary at all.
> > 
> > I see that get_langinfo() calls __loadlocale and performs a lot of stuff
> > on the charsets which looks like duplicates of the initial_setlocale()
> > call performed at DLL startup.
> > 
> > If there's anything missing in the initial_setlocale() call which would
> > be required by the pseudo tty code?  What exactly is it?  The codepage?
> > And why can't we just add the info to cygheap->locale at initial_setlocale()
> > time so it's available at exec time without going through all this hassle
> > every time?
> > 
> > Apart from that, all this locale/charset/lcid stuff should be concentrated
> > in nlsfunc.cc ideally.
> 
> get_locale_from_env() and get_langinfo() should go away.  If we just
> need a codepage for get_ttyp ()->term_code_page, we should really find a
> way to do this from within internal_setlocale().

I looked into internal_setlocale() code, but I could not found
the code which handles thecode page. I found the code handling
the code page in __set_charset_from_locale() function in nlsfuncs.cc,
but it does not return code page itself. Could you please explain
more detail of your idea?

-- 
Takashi Yano 

Re: Cron installation issue

[Anantha . Kumar]

Hi Marco,

You must run service config scripts from an elevated admin shell.
Yes, I have executed using elevated admin shell but the same error I am getting.




Thanks,

Anantha Kumar

Platform Support

Elait
 Mobile: +91 9600406739

 Email :   anantha.ku...@elait.com

P Please consider the environment before printing this e-mail. Thank you.

Unless otherwise stated, the content of this email is confidential and intended 
for the specified recipient. Please seek permission in advance before sharing 
any of its contents. If received in error; please reply so we are aware and 
delete it.





From: marco atzeri 
Sent: Wednesday, September 2, 2020 3:05 PM
To: Anantha.Kumar 
Cc: cygwin@cygwin.com 
Subject: Re: Cron installation issue

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On Wed, Sep 2, 2020 at 11:13 AM Anantha.Kumar  wrote:
>
> Hi Team,
>
> Do you have any advice on this failure.

Again:
You must run service config scripts from an elevated admin shell.

It seems very simple to me. Or do you not understand its meaning ?

Regards
Marco
This E-mail is confidential. It may also be legally privileged. If you are not 
the addressee you may not copy, forward, disclose or use any part of it. If you 
have received this message in error, please delete it and all copies from your 
system and notify the sender immediately by return E-mail.

Confidential
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Takashi Yano via Cygwin-patches]

On Wed, 2 Sep 2020 10:30:14 +0200
Corinna Vinschen wrote:
> On Sep  1 18:19, Johannes Schindelin wrote:
> > When `LANG=en_US.UTF-8`, the detected `LCID` is 0x0409, which is
> > correct, but after that (at least if Pseudo Console support is enabled),
> > we try to find the default code page for that `LCID`, which is ASCII
> > (437). Subsequently, we set the Console output code page to that value,
> > completely ignoring that we wanted to use UTF-8.
> > 
> > Let's not ignore the specifically asked-for UTF-8 character set.
> > 
> > While at it, let's also set the Console output code page even if Pseudo
> > Console support is disabled; contrary to the behavior of v3.0.7, the
> > Console output code page is not ignored in that case.
> > 
> > The most common symptom would be that console applications which do not
> > specifically call `SetConsoleOutputCP()` but output UTF-8-encoded text
> > seem to be broken with v3.1.x when they worked plenty fine with v3.0.x.
> > 
> > This fixes https://github.com/msys2/MSYS2-packages/issues/1974,
> > https://github.com/msys2/MSYS2-packages/issues/2012,
> > https://github.com/rust-lang/cargo/issues/8369,
> > https://github.com/git-for-windows/git/issues/2734,
> > https://github.com/git-for-windows/git/issues/2793,
> > https://github.com/git-for-windows/git/issues/2792, and possibly quite a
> > few others.
> > 
> > Signed-off-by: Johannes Schindelin 
> > ---
> >  winsup/cygwin/fhandler_tty.cc | 9 +
> >  1 file changed, 9 insertions(+)
> 
> Ok guys, I'm not opposed to this change in terms of its result,

I am sorry, but I cannot agree with Johannes's patch.

For example, code page in Japan is CP932 by default.
In this case, cmd.exe, netsh.exe and so on are generate
messages in Japanese.

If the code page is set to CP_UTF8, messages from such
commands changes to english. I guess similar things happen
for other locales.

I do not prefer this result.

Furthermore, I looked into the issue:
https://github.com/git-for-windows/git/issues/2734
and I found that git-for-windows always use utf-8
encoding even if the locale is ja_JP.CP932.
It does not change coding based on locale or code
page.

Even with Johannes's patch, if mintty is started with
locale ja_JP.CP932, the file name will be garbled
bacause SetConsoleOutputCP(CP_UTF8) will not be called.

IMHO, it is the problem of git-for-windows rather
than cygwin and msys2.

To make current version of git-for-windows work, it is
necessary to set code page to CP_UTF8 regardless locale.
This does not make sense at all.

-- 
Takashi Yano 

Re: Cron installation issue

[marco atzeri via Cygwin]

On Wed, Sep 2, 2020 at 11:13 AM Anantha.Kumar  wrote:
>
> Hi Team,
>
> Do you have any advice on this failure.

Again:
You must run service config scripts from an elevated admin shell.

It seems very simple to me. Or do you not understand its meaning ?

Regards
Marco
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Cron installation issue

[Anantha . Kumar]

Hi Team,

Do you have any advice on this failure.




Thanks,

Anantha Kumar

Platform Support

Elait
 Mobile: +91 9600406739

 Email :   anantha.ku...@elait.com

P Please consider the environment before printing this e-mail. Thank you.

Unless otherwise stated, the content of this email is confidential and intended 
for the specified recipient. Please seek permission in advance before sharing 
any of its contents. If received in error; please reply so we are aware and 
delete it.





From: Anantha.Kumar 
Sent: Tuesday, September 1, 2020 5:47 PM
To: cygwin@cygwin.com ; brian.ing...@systematicsw.ab.ca 

Subject: Re: Cron installation issue

Hi Brain,

Yes, I was trying to run through admin shell but still facing this issue.



Thanks,

Anantha Kumar

Platform Support

Elait
 Mobile: +91 9600406739

 Email :   anantha.ku...@elait.com

P Please consider the environment before printing this e-mail. Thank you.

Unless otherwise stated, the content of this email is confidential and intended 
for the specified recipient. Please seek permission in advance before sharing 
any of its contents. If received in error; please reply so we are aware and 
delete it.





From: Brian Inglis 
Sent: Friday, August 28, 2020 7:34 PM
To: cygwin@cygwin.com 
Cc: Anantha.Kumar 
Subject: Re: Cron installation issue

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


On 2020-08-28 03:35, Anantha.Kumar wrote:
> I am facing some issue while installing cron as a windows service. I have
> attached the error message and cronbug output. Could you please help us on
> this issue?

> Do you want to start the cron daemon as a service now? (yes/no) yes
> cygrunsrv: Error starting a service: QueryServiceStatus:  Win32 error 1062:
> The service has not been started.


You must run service config scripts from an elevated admin shell.

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
This E-mail is confidential. It may also be legally privileged. If you are not 
the addressee you may not copy, forward, disclose or use any part of it. If you 
have received this message in error, please delete it and all copies from your 
system and notify the sender immediately by return E-mail.

Confidential
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Corinna Vinschen]

On Sep  2 10:30, Corinna Vinschen wrote:
> On Sep  1 18:19, Johannes Schindelin wrote:
> > When `LANG=en_US.UTF-8`, the detected `LCID` is 0x0409, which is
> > correct, but after that (at least if Pseudo Console support is enabled),
> > we try to find the default code page for that `LCID`, which is ASCII
> > (437). Subsequently, we set the Console output code page to that value,
> > completely ignoring that we wanted to use UTF-8.
> > 
> > Let's not ignore the specifically asked-for UTF-8 character set.
> > 
> > While at it, let's also set the Console output code page even if Pseudo
> > Console support is disabled; contrary to the behavior of v3.0.7, the
> > Console output code page is not ignored in that case.
> > 
> > The most common symptom would be that console applications which do not
> > specifically call `SetConsoleOutputCP()` but output UTF-8-encoded text
> > seem to be broken with v3.1.x when they worked plenty fine with v3.0.x.
> > 
> > This fixes https://github.com/msys2/MSYS2-packages/issues/1974,
> > https://github.com/msys2/MSYS2-packages/issues/2012,
> > https://github.com/rust-lang/cargo/issues/8369,
> > https://github.com/git-for-windows/git/issues/2734,
> > https://github.com/git-for-windows/git/issues/2793,
> > https://github.com/git-for-windows/git/issues/2792, and possibly quite a
> > few others.
> > 
> > Signed-off-by: Johannes Schindelin 
> > ---
> >  winsup/cygwin/fhandler_tty.cc | 9 +
> >  1 file changed, 9 insertions(+)
> 
> Ok guys, I'm not opposed to this change in terms of its result,
> but I'm starting to wonder why all this locale code in fhandler_tty
> is necessary at all.
> 
> I see that get_langinfo() calls __loadlocale and performs a lot of stuff
> on the charsets which looks like duplicates of the initial_setlocale()
> call performed at DLL startup.
> 
> If there's anything missing in the initial_setlocale() call which would
> be required by the pseudo tty code?  What exactly is it?  The codepage?
> And why can't we just add the info to cygheap->locale at initial_setlocale()
> time so it's available at exec time without going through all this hassle
> every time?
> 
> Apart from that, all this locale/charset/lcid stuff should be concentrated
> in nlsfunc.cc ideally.

get_locale_from_env() and get_langinfo() should go away.  If we just
need a codepage for get_ttyp ()->term_code_page, we should really find a
way to do this from within internal_setlocale().


Corinna

Re: [PATCH 3/3] fhandler_pty_slave::setup_locale: respect charset == "UTF-8"

[Corinna Vinschen]

On Sep  1 18:19, Johannes Schindelin wrote:
> When `LANG=en_US.UTF-8`, the detected `LCID` is 0x0409, which is
> correct, but after that (at least if Pseudo Console support is enabled),
> we try to find the default code page for that `LCID`, which is ASCII
> (437). Subsequently, we set the Console output code page to that value,
> completely ignoring that we wanted to use UTF-8.
> 
> Let's not ignore the specifically asked-for UTF-8 character set.
> 
> While at it, let's also set the Console output code page even if Pseudo
> Console support is disabled; contrary to the behavior of v3.0.7, the
> Console output code page is not ignored in that case.
> 
> The most common symptom would be that console applications which do not
> specifically call `SetConsoleOutputCP()` but output UTF-8-encoded text
> seem to be broken with v3.1.x when they worked plenty fine with v3.0.x.
> 
> This fixes https://github.com/msys2/MSYS2-packages/issues/1974,
> https://github.com/msys2/MSYS2-packages/issues/2012,
> https://github.com/rust-lang/cargo/issues/8369,
> https://github.com/git-for-windows/git/issues/2734,
> https://github.com/git-for-windows/git/issues/2793,
> https://github.com/git-for-windows/git/issues/2792, and possibly quite a
> few others.
> 
> Signed-off-by: Johannes Schindelin 
> ---
>  winsup/cygwin/fhandler_tty.cc | 9 +
>  1 file changed, 9 insertions(+)

Ok guys, I'm not opposed to this change in terms of its result,
but I'm starting to wonder why all this locale code in fhandler_tty
is necessary at all.

I see that get_langinfo() calls __loadlocale and performs a lot of stuff
on the charsets which looks like duplicates of the initial_setlocale()
call performed at DLL startup.

If there's anything missing in the initial_setlocale() call which would
be required by the pseudo tty code?  What exactly is it?  The codepage?
And why can't we just add the info to cygheap->locale at initial_setlocale()
time so it's available at exec time without going through all this hassle
every time?

Apart from that, all this locale/charset/lcid stuff should be concentrated
in nlsfunc.cc ideally.


Thanks,
Corinna

Re: cpp /usr/include/threads.h fails; modfl segfaults

[Corinna Vinschen]

On Sep  1 11:28, Brian Inglis wrote:
> On 2020-08-31 13:41, Corinna Vinschen wrote:
> > On Aug 31 13:24, Brian Inglis wrote:
>  The upstream patch changed only amd64/x86_64 code sequences for multiple 
>  modules
>  including modfl, and left i386/x86 untouched for those modules.
> >>
> >> Just pointing out that they only modify their amd64/x86_64 code which 
> >> doesn't
> >> push/pop rax/eax:
> > 
> > Where are you looking at?  As you could see from my output, I was
> > looking at the master branch of the upstream repo.
> 
> Sorry I didn't see your point there as I wasn't aware there were SF repos.
> 
> > This lengthy discussion for a minor asm snippet doesn't make any sense.
> > If you think this is wrong, send patches to cygwin-patches and explain
> > where you got it from, preferrably as a git patch from the upstream
> > repo.
> 
> Sorry for wasting your time.
> I was looking at the bug/patch content and didn't realize someone later added 
> a
> bogus clobber on their x86 code path.

No, really, patches are super great and *I* know *you* know how it works.

Given this code is at least questionable, what about sending a patch to
upstream and a matching patch to cygwin-patches?  The upstream mailing
list is at mingw-w64-public AT lists DOT sourceforge DOT net.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: cygwin qsort erratic

[Thomas Wolff]

Am 02.09.2020 um 02:26 schrieb Kurt-Karen Carlson-Lougheed:

Thomas:
As stated, twice, the full code is on SourceForge as uac19 v3.3. If 
you need me to send you a tgz with sample data please let me know, but 
note the comments and patch below. I can certainly walk you through 
reproducing the problem if you believe that is worthwhile.

Kurt-Karen:
I am not uac savvy. The proposal to dig out some software package, build 
it (which may create hours-long trouble in some cases), collect data 
from somewhere else etc, to reproduce an assumed bug, is not 
appropriate. It's your term to provide a single, reproducible 
demonstration of a bug. If this were an issue in my project, I would 
close it now for refusal of cooperation.




Stephen:
Thank you. I couldn't get the 'blame' to work (I am not git savvy), 
but I got the cygwin qsort.c. The problem is *EXACTLY* as described by 
Dennis de Champeaux in the 2015-01-11 cygwin list posting. The 
secondary insertion sort attempt is not safe. I patched as follows, 
the de Champeaux is code is more correct in removing swap_cnt as it is 
no longer used:


kc: diff -u qsort.c cygsort.c
--- qsort.c     2020-09-01 15:36:39.716029300 -0700
+++ cygsort.c   2020-09-01 16:47:30.152545600 -0700
@@ -252,14 +252,15 @@
                pb += es;
                pc -= es;
        }
-       if (swap_cnt == 0) {  /* Switch to insertion sort */
+/* kc
+       if (swap_cnt == 0) {  // Switch to insertion sort
                for (pm = (char *) a + es; pm < (char *) a + n * es; 
pm += es)
                        for (pl = pm; pl > (char *) a && CMP(thunk, pl 
- es, pl) > 0;

                             pl -= es)
                                swap(pl, pl - es);
                goto pop;
        }
-
+kc */
        /*
         * Rearrange the array in three parts sorted like this:
         * { elements < pivot, elements == pivot, elements > pivot }

If you need me to provide further information, please advise.
Regards, kurt

On Tue, Sep 1, 2020 at 3:02 PM Thomas Wolff > wrote:


Am 01.09.2020 um 22:29 schrieb Kurt-Karen Carlson-Lougheed via Cygwin:
>    Brian:
> 1. The Qsort() source I sent was from netbsd.org
, NOT cygwin. netbsd works.
> 2. Complete package is on SourceForge as uac19 v3.3. I'm happy
to send a
> tgz if you prefer that. Read 3 choices at end before considering
this.
> 3. Data is curl'd from owid as shown in the script example.
Likewise I can
> send a sample data set. The program analyzes COVID-19 csv files
from either
> owid or github/nytimes
> 4. I've used qsort() for years. I agree, keeping the sort
routines simple
> is always appropriate. I confirmed today the only ones that fail
include
> float divides, lDsort() and lXsort() in attached c19sort.c. When
it's
> pre-calculated and added to the struct it works, the code has a
toggle now
> for testing that.
>
> Thomas:
> I tried (again) today  to build a simple test case. The data
structures in
> use are complex, probably the only thing I can attempt is
stripping down
> the code which will be very time consuming. I know you don't
know me at
> all, but I've written code, debugged proprietary operating systems
> (assembler), performed OS dump analysis, troubleshot
intermittent hardware
> issues, identified disk firmware issues causing intermittent data
> corruption, identified nfs performance issues, managed large hpc
clusters,
> etc. etc. etc. over 40+ years.
Your code does not even compile. I did not ask for a minimal test
case
although that is generally appreciated. But a working test case at
least
is required to establlish your claim of a bug.
>
> I see three choices:
> A. One of you look at simple the qqsort wrapper. I modified my
code to
> toggle between the functional netbsd Qsort() and cygwin qsort().
I have
> demonstrated erroneous results coming from the cygwin version in
a small
> percentage of requests. If you can acknowledge that, perhaps you
can check
> the cygwin version of qsort() vs. the current netbsd.org
?
> B. If you could kindly provide me or point me to the cygwin
qsort() source
> I'll check it out myself.
> C. We can thank each other and leave cygwin's qsort() as is
broken in some
> small number of circumstances since I've compiled netbsd's into
my code and
> that always works.
>
> Regards, kurt
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: