ssh to cygwin-box and access remote exe fails saying exe is a directory
Hi All, I am trying to access an exe hosted in a shared drive in a remote machine. (Please note: T*he exe is NOT hosted on the box where cygwin is installed but a different one*.) *Case 1: Which fails* If i ssh to the Windows box where cygwin is installed, and then try to access the remote exe it *fails saying "exe is a directory"* [rundeck@den PKG_INSTALL_SERVICE]$ cat snapshot1.bat | ssh rsanpui@cygwin-box Pseudo-terminal will not be allocated because stdin is not a terminal. -bash: line 1: //remote-box/owshare/owinstal/Snapshot/SnapShot.exe: *Is a directory* What i have inside snapshot1.bat is simple - [rundeck@den PKG_INSTALL_SERVICE]$ cat snapshot1.bat "//remote-box/owshare/owinstal/Snapshot/SnapShot.exe" *Case 2: Which works* If i login to the Windows VM where cygwin is installed, and try to access the same remote exe it works. What am I missing? Please advise. Thanks -- 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] Updated: qrencode 4.1.1-1 (test)
Hi! qrencode and its library packages have been updated to the latest upstream. The following packages have been uploaded as test: * qrencode-4.1.1-1-src.tar.xz * qrencode-4.1.1-1.tar.xz * libqrencode-devel-4.1.1-1.tar.xz * libqrencode4-4.1.1-1.tar.xz * qrencode-debuginfo-4.1.1-1.tar.xz QR Code symbol library Libqrencode is a C library for encoding data in a QR Code symbol, a kind of 2D symbology that can be scanned by handy terminals such as a mobile phone with CCD. The capacity of QR Code is up to 7000 digits or 4000 characters, and is highly robust. HOMEPAGE: https://fukuchi.org/works/qrencode/index.en.html NEWS: https://github.com/fukuchi/libqrencode/blob/v4.1.1/NEWS Please, test this release, and report any issues. -- Lemures Lemniscati -- 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
Updated: qrencode 4.1.1-1 (test)
Hi! qrencode and its library packages have been updated to the latest upstream. The following packages have been uploaded as test: * qrencode-4.1.1-1-src.tar.xz * qrencode-4.1.1-1.tar.xz * libqrencode-devel-4.1.1-1.tar.xz * libqrencode4-4.1.1-1.tar.xz * qrencode-debuginfo-4.1.1-1.tar.xz QR Code symbol library Libqrencode is a C library for encoding data in a QR Code symbol, a kind of 2D symbology that can be scanned by handy terminals such as a mobile phone with CCD. The capacity of QR Code is up to 7000 digits or 4000 characters, and is highly robust. HOMEPAGE: https://fukuchi.org/works/qrencode/index.en.html NEWS: https://github.com/fukuchi/libqrencode/blob/v4.1.1/NEWS Please, test this release, and report any issues. -- Lemures Lemniscati
RE: Date of first Cygwin release / 25th Anniversary
> -Original Message- > From: Cygwin On Behalf Of Corinna > Vinschen > Sent: Tuesday, October 13, 2020 2:51 PM > To: cygwin@cygwin.com > Subject: Re: Date of first Cygwin release / 25th Anniversary > > On Sep 23 19:53, Kevin Schnitzius via Cygwin wrote: > > On Wednesday, September 23, 2020, 02:33:13 PM EDT, David Eisner via > Cygwin wrote: > > > > > In any case, happy 25th anniversary, Cygwin! Thanks to everybody who > made it and continues to make it possible. > > I purchased the 1.0 release CD in 1999: > > https://imgur.com/2UnLDhk > > I still have a shrink-wrapped 1.0 package, never opened since we had two of > them. This pristine copy is probably worth millions now!1!11 > I have a book to go with the CD: https://imgur.com/jiAll5X My un-used registration code expired 24 years and 11 months ago! Congrats on the 25th Cygwin and contributors, /allen Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender. -- 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: [ITA] po4a
Erwin Waterlander writes: > I would like to adopt orphaned package po4a. When you update the cygport file, please include a REQUIRES for perl5_030 to ease the transition when Perl next upgrades in a binary incompatible way. Thank you for adopting the package! Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: test -r or -x always return false on an NFS mount?
Hi Corinna, great to have you back :-) On 13.10.20 20:36, Corinna Vinschen wrote: On Oct 6 18:10, Mario Emmenlauer wrote: Dear Andrey, On 06.10.20 17:46, Andrey Repin wrote: Greetings, Mario Emmenlauer! thanks for the awesome Cygwin, its really great! Everything seems to work quite well, and in `ls -la` I can see the file permissions and user and group entries. But when using `test` to check for read (`test -r`) or execute permissions (`test -x`), it always returns false, even for readable files. `ls` on the other hand shows the permissions correctly, and `cat`ing the files works without problems. This is a known issue. For years known. test only guess -r/-w/-x results based on permissions as it sees them. But it do not actually try to read/write/execute the subject, which, as you can imagine, may lead to all sorts of false positives/negatives on filesystems with less than trivial access control setups. In other words, don't test for rwx if you can avoid it. The results MAY be wrong. Ok, this explains a lot, and I almost guessed as much! But can I ask, do you happen to know why `ls -l` shows the "correct" permissions including 'r' and 'x'? It seems `ls` has some magic that `test` is lacking? And I can not imagine that `ls` would try to open every file, or does it?. So could this "magic" be ported from `ls` to `test`? There's something fishy in your environment. NFS permissions from NFS shares mounted via Microsoft's NFSv3 are read using some internal function I got hinted at by the MSFT NFS guys at one point. This information is then exported as mode bits by Cygwin's stat(2) and used accordingly by Cygwin's access(2). Having said that, there's *no* magic at all in the user space applications other than using Cygwin's stat(2) and access(2) functions. Consequentially, using Cygwin's ls(1) or test(1) from coreutils, the results are the expected ones in both cases; just tried it myself, just to be sure. So, what's fishy? I don't know, but maybe you're using a non-Cygwin test(1) accidentally? I see your point, but to the best of my knowledge there is nothing fishy. Its a freshly set up computer with an official Windows 10 x64 from Microsoft directly. I've installed all latest updates including the 2004 update. Cygwin was also just installed a few months ago. I did use a script to install Cygwin via its installer in an automated fashion, but I've run the normal, graphical installer a few times since then to make sure everything is nice and clean. Calling "which test" shows "/usr/bin/test", but since I use only bash in all my scripts, I guess it anyways defaults to the builtin. The only "weak link" in my setup is the NFS mount. I'm no expert in exporting NFS, nor in mounting NFS from Windows. Maybe something is fishy there, albeit I did not use any special parameters or quirks (again, to the best of my knowledge). What I can say is that I'm limited to NFS v3 since its not a Server-Edition Windows. Also, I tried my best to open all NFS ports in the firewall but possibly I'm not running one of the many extended NFS services like lockd or something. I checked that most are installed, running and use a static port, but its hard to be sure, since NFS seems to support quite many "extras". Is there anything I can do to isolate this further? Its a quite curious case and I'm basically at the end of my wit... All the best, Mario -- 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: Date of first Cygwin release / 25th Anniversary
On Sep 23 19:53, Kevin Schnitzius via Cygwin wrote: > On Wednesday, September 23, 2020, 02:33:13 PM EDT, David Eisner via Cygwin > wrote: > > > In any case, happy 25th anniversary, Cygwin! Thanks to everybody who made > > it and continues to make it possible. > I purchased the 1.0 release CD in 1999: > https://imgur.com/2UnLDhk I still have a shrink-wrapped 1.0 package, never opened since we had two of them. This pristine copy is probably worth millions now!1!11 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: test -r or -x always return false on an NFS mount?
On Oct 6 18:10, Mario Emmenlauer wrote: > > Dear Andrey, > > On 06.10.20 17:46, Andrey Repin wrote: > > Greetings, Mario Emmenlauer! > > > >> thanks for the awesome Cygwin, its really great! > > > >> Everything seems to work quite well, and in `ls -la` I can see the > >> file permissions and user and group entries. But when using `test` > >> to check for read (`test -r`) or execute permissions (`test -x`), it > >> always returns false, even for readable files. `ls` on the other hand > >> shows the permissions correctly, and `cat`ing the files works without > >> problems. > > > > This is a known issue. For years known. > > test only guess -r/-w/-x results based on permissions as it sees them. > > But it do not actually try to read/write/execute the subject, which, as you > > can imagine, may lead to all sorts of false positives/negatives on > > filesystems > > with less than trivial access control setups. > > In other words, don't test for rwx if you can avoid it. The results MAY be > > wrong. > > > Ok, this explains a lot, and I almost guessed as much! But can I ask, > do you happen to know why `ls -l` shows the "correct" permissions > including 'r' and 'x'? It seems `ls` has some magic that `test` is > lacking? And I can not imagine that `ls` would try to open every > file, or does it?. > > So could this "magic" be ported from `ls` to `test`? There's something fishy in your environment. NFS permissions from NFS shares mounted via Microsoft's NFSv3 are read using some internal function I got hinted at by the MSFT NFS guys at one point. This information is then exported as mode bits by Cygwin's stat(2) and used accordingly by Cygwin's access(2). Having said that, there's *no* magic at all in the user space applications other than using Cygwin's stat(2) and access(2) functions. Consequentially, using Cygwin's ls(1) or test(1) from coreutils, the results are the expected ones in both cases; just tried it myself, just to be sure. So, what's fishy? I don't know, but maybe you're using a non-Cygwin test(1) accidentally? Corinna -- 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 2/8] Drop STDINCFLAGS overrides
On Oct 13 18:36, Jon Turney wrote: > On 13/10/2020 13:10, Corinna Vinschen wrote: > > On Oct 12 20:29, Jon Turney wrote: > > > This used to turn off -nostdinc on a per-file basis, but has no effect > > > since 4c36016b. > > > > I'd prefer a longer SHA-1, at least 12 chars. Maybe we should > > With ~20K commits in the repository, the chance of a hash collision in the > first 32 bits (~~ 4*10^9) seems pretty small, but sure. > > > add a "Fixes: ..." along the lines of the Linux kernel from now on? > > This doesn't actually fix anything, just removes some cruft. Point. > > Ideally we'd get rid of ccwrap/c++wrap, too... > > Working on it :) \o/ Corinna
Re: [PATCH] format_proc_cpuinfo: add enqcmd cpuinfo flag
On Oct 13 09:11, Brian Inglis wrote: > Add linux-next 5.9 cpuinfo flag for Intel enqcmd/s instructions: > x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions: > Work submission instruction comes in two flavors. ENQCMD can be called > both in ring 3 and ring 0 and always uses the contents of a PASID MSR > when shipping the command to the device. ENQCMDS allows a kernel driver > to submit commands on behalf of a user process. The driver supplies the > PASID value in ENQCMDS. There isn't any usage of ENQCMD in the kernel as > of now. > The CPU feature flag is shown as "enqcmd" in /proc/cpuinfo. > --- > winsup/cygwin/fhandler_proc.cc | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc > index 6f6e8291a0ca..13397150ff53 100644 > --- a/winsup/cygwin/fhandler_proc.cc > +++ b/winsup/cygwin/fhandler_proc.cc > @@ -1563,6 +1563,7 @@ format_proc_cpuinfo (void *, char *) > ftcprint (features1, 25, "cldemote"); /* cldemote instr */ > ftcprint (features1, 27, "movdiri"); /* movdiri instr */ > ftcprint (features1, 28, "movdir64b");/* movdir64b instr */ > + ftcprint (features1, 29, "enqcmd"); /* enqcmd/s > instructions*/ > } > >/* AMD MCA cpuid 0x8007 ebx */ > -- > 2.28.0 Pushed. Thanks, Corinna
Re: [PATCH 2/8] Drop STDINCFLAGS overrides
On 13/10/2020 13:10, Corinna Vinschen wrote: On Oct 12 20:29, Jon Turney wrote: This used to turn off -nostdinc on a per-file basis, but has no effect since 4c36016b. I'd prefer a longer SHA-1, at least 12 chars. Maybe we should With ~20K commits in the repository, the chance of a hash collision in the first 32 bits (~~ 4*10^9) seems pretty small, but sure. add a "Fixes: ..." along the lines of the Linux kernel from now on? This doesn't actually fix anything, just removes some cruft. Ideally we'd get rid of ccwrap/c++wrap, too... Working on it :)
Re: Unconsistent command-line parsing in case of UTF-8 quoted arguments
On 2020-10-06 15:36, Jérôme Froissart wrote:
> Here are the more detailed steps to reproduce the issue (along with
> answers to your requests about `uname`, `locale`, etc.).
> (I mostly reproduced what billziss-gh had done before, I do not take
> all the credits :D)
>
> Here is an example C file
> $ cat example.c
> #include
>
> const char *GetCommandLineA(void);
>
> int main(int argc, char *argv[])
> {
> const char *s = GetCommandLineA();
> printf("C=%s\n", s);
>
> for (int i = 0; argc > i; i++)
> printf("%d=%s\n", i, argv[i]);
>
> return 0;
> }
>
> I have built it with gcc from Cygwin
> $ gcc -o binary example.c
>
> Running it from the same Cygwin bash prompt works as expected
> $ uname -a
> CYGWIN_NT-10.0 XPS 3.1.5(0.340/5/3) 2020-06-01 08:59 x86_64 Cygwin
> # (XPS is my Windows machine name)
>
> $ locale
> LANG=fr_FR.UTF-8
> LC_CTYPE="fr_FR.UTF-8"
> LC_NUMERIC="fr_FR.UTF-8"
> LC_TIME="fr_FR.UTF-8"
> LC_COLLATE="fr_FR.UTF-8"
> LC_MONETARY="fr_FR.UTF-8"
> LC_MESSAGES="fr_FR.UTF-8"
> LC_ALL=
>
> $ which gcc
> /usr/bin/gcc
>
> # The following runs as expected
> $ ./binary.exe "foo bar" "Jérôme"
> C="C:\Users\Public\binary.exe"
> 0=./binary
> 1=foo bar
> 2=Jérôme
>
> Now, let's start a Windows shell (cmd.exe)
> Note that I had to copy cygwin1.dll from my Cygwin installation
> directory, otherwise binary.exe would not start.
> I do not know whether there is a `locale` equivalent in Windows
> command prompt, so I merely ran my program.
> C:\Users\Public>binary.exe "foo bar" "Jérôme"
> C=binary.exe "foo bar" "J□r□me"
> 0=binary
> 1=foo bar
> 2="Jérôme"
>
> This behaviour is not expected and is quite inconsistent with what
> happened through Bash.
> Besides the "strange squares" that appear on the first line, and the
> extra space after binary.exe, I especially did not expect "Jérôme" to
> remain quoted as a second argument.
Don't call inappropriate Windows functions without understanding the limitations
of Windows and its APIs.
Cygwin args are consistent with what you ran and what we would all expect.
I don't see any Cygwin problems here.
--
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 binary units and prefixes, physical quantities in SI.]
--
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: [ITA] po4a
On 10/13/2020 2:48 AM, Erwin Waterlander wrote: Hi, I would like to adopt orphaned package po4a. Please show us your proposed cygport file and any patches. Ideally, your cygport file would have an accurate BUILD_REQUIRES so that anyone can do a test build. Ken
Re: Unconsistent command-line parsing in case of UTF-8 quoted arguments
On 2020-10-06 14:36, Jérôme Froissart wrote:
Here is an example C file
$ cat example.c
#include
const char *GetCommandLineA(void);
int main(int argc, char *argv[])
{
const char *s = GetCommandLineA();
printf("C=%s\n", s);
for (int i = 0; argc > i; i++)
printf("%d=%s\n", i, argv[i]);
return 0;
}
Your program's comparison seems to be based on the
hypothesis that Cygwin parses the GetCommandLineA() command line.
But this hypothesis is almost certainly wrong.
Now, let's start a Windows shell (cmd.exe)
Note that I had to copy cygwin1.dll from my Cygwin installation
directory, otherwise binary.exe would not start.
I do not know whether there is a `locale` equivalent in Windows
command prompt, so I merely ran my program.
C:\Users\Public>binary.exe "foo bar" "Jérôme"
C=binary.exe "foo bar" "J□r□me"
0=binary
1=foo bar
2="Jérôme"
The "A" command line from GetCommandLineA has "tofu"
characters: é and ô were not decoded properly.
The é and ô characters we see in the Cygwin-parsed
arguments coming into main could not have been recovered
from these "tofu" replacement characters.
What is actually being parsed must be the WCHAR command line
corresponding to what comes from GetCommandLineW().
It's necessary to show that one to get a more complete understanding.
--
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 v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS
On Oct 13 13:18, Ken Brown via Cygwin-patches wrote: > On 10/13/2020 7:28 AM, Corinna Vinschen wrote: > > On Oct 4 12:49, Ken Brown via Cygwin-patches wrote: > >> A successful connection can be indicated by STATUS_SUCCESS or > >> STATUS_PIPE_CONNECTED. > > > > THanks for catching but... huh? How does Windows generate two different > > status codes for the same result from the same function? > > I think (but I'd have to recheck) that if the pipe is already connected when > NtFsControlFile is called, then the latter returns STATUS_PIPE_CONNECTED. > But > if you first get STATUS_PENDING and then set status = io.Status after > completion, then the result is STATUS_SUCCESS. Ah, ok. I guess I just missed this scenario for some reason. Thanks, Corinna
[PATCH] format_proc_cpuinfo: add enqcmd cpuinfo flag
Add linux-next 5.9 cpuinfo flag for Intel enqcmd/s instructions: x86/cpufeatures: Enumerate ENQCMD and ENQCMDS instructions: Work submission instruction comes in two flavors. ENQCMD can be called both in ring 3 and ring 0 and always uses the contents of a PASID MSR when shipping the command to the device. ENQCMDS allows a kernel driver to submit commands on behalf of a user process. The driver supplies the PASID value in ENQCMDS. There isn't any usage of ENQCMD in the kernel as of now. The CPU feature flag is shown as "enqcmd" in /proc/cpuinfo. --- winsup/cygwin/fhandler_proc.cc | 1 + 1 file changed, 1 insertion(+) diff --git a/winsup/cygwin/fhandler_proc.cc b/winsup/cygwin/fhandler_proc.cc index 6f6e8291a0ca..13397150ff53 100644 --- a/winsup/cygwin/fhandler_proc.cc +++ b/winsup/cygwin/fhandler_proc.cc @@ -1563,6 +1563,7 @@ format_proc_cpuinfo (void *, char *) ftcprint (features1, 25, "cldemote"); /* cldemote instr */ ftcprint (features1, 27, "movdiri"); /* movdiri instr */ ftcprint (features1, 28, "movdir64b");/* movdir64b instr */ + ftcprint (features1, 29, "enqcmd"); /* enqcmd/s instructions*/ } /* AMD MCA cpuid 0x8007 ebx */ -- 2.28.0
Re: [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS
On 10/13/2020 7:28 AM, Corinna Vinschen wrote: > On Oct 4 12:49, Ken Brown via Cygwin-patches wrote: >> A successful connection can be indicated by STATUS_SUCCESS or >> STATUS_PIPE_CONNECTED. > > THanks for catching but... huh? How does Windows generate two different > status codes for the same result from the same function? I think (but I'd have to recheck) that if the pipe is already connected when NtFsControlFile is called, then the latter returns STATUS_PIPE_CONNECTED. But if you first get STATUS_PENDING and then set status = io.Status after completion, then the result is STATUS_SUCCESS. I might not have that exactly right. All I remember for sure is that I was debugging a listen_pipe failure, and it turned out to be due to STATUS_SUCCESS being treated as an error condition. Ken
Problem with cp.exe (in Cygwin 3.6 64 bit): permission preserve
Hello Cygwin Team, We are upgrading Cygwin from 1.7.31 32 bit to 3.6 64 bit. With the earlier version, 'cp -fp' command used to work without any error. Now, we get an error like, 'cp: preserving permissions for not supported. Here is my understanding about ACLs & File permission in Cygwin: Windows ACLs will be translated/mapped to POSIX like in Cygwin (This includes user, group & permissions). Cygwin uses some logic to implement this (using Solaris API, using SFU, ACEs accumulated for the 'access allowed' etc.) I understand that, POSIX style is introduced from version 1.7.34. If my understanding is correct, prior to version 1.7.34, it was using UNIX like permission(not POSIX). In both cases (UNIX/POSIX), permission preserve has no real meaning. To disable this translation(to UNIX/POSIX), we had to set 'nontsec' CYGWIN variable in old Cygwin and we have to set 'noacl' in /etc/fastab for the new Cygwin But my question here is, 'cp -fp' was working with Cygwin 1.7.31. Why it is NOT working now with Cygwin 3.6? Note: We were NOT using 'nontsec' before & now, it's equivalent 'noacl' is also not used. If I use 'noacl' in the cygwin, 'cp -fp' doesn't complain. Regards Vinay Hegde -- 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 2/8] Drop STDINCFLAGS overrides
On Oct 12 20:29, Jon Turney wrote: > This used to turn off -nostdinc on a per-file basis, but has no effect > since 4c36016b. I'd prefer a longer SHA-1, at least 12 chars. Maybe we should add a "Fixes: ..." along the lines of the Linux kernel from now on? Ideally we'd get rid of ccwrap/c++wrap, too... Corinna
Re: [PATCH] Cygwin: pty: Add workaround for ISO-2022 and ISCII in convert_mb_str().
On Sep 12 04:11, Takashi Yano via Cygwin-patches wrote: > On Fri, 11 Sep 2020 20:57:06 +0200 > Corinna Vinschen wrote: > > On Sep 12 03:37, Takashi Yano via Cygwin-patches wrote: > > > On Sat, 12 Sep 2020 02:38:43 +0900 > > > Takashi Yano via Cygwin-patches wrote: > > > > How about the patch attached? > > > > I think this is safer than previous patch. > > > > > > I have revised this patch to fit current git head, and submit > > > to cygwin-patches@cygwin.com. > > > > Thanks, but I didn't apply this one because it doesn't really make sense > > to go to the extra effort to support outdated and incompatible codepages > > we don't handle as Cygwin codeset at all. IMHO it's not worth to call > > another MBTWC just to check if a codepage supports the MB_ERR_INVALID_CHARS > > flag. > > I have checked which codepage does not support MB_ERR_INVALID_CHARS. > The result is as follows. > > 42 > 50220 > 50221 > 50222 > 50225 > 50227 > 50229 > 52936 > 57002 > 57003 > 57004 > 57005 > 57006 > 57007 > 57008 > 57009 > 57010 > 57011 > 65000 Yup, these are documented on MSDN: https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-widechartomultibyte > If all of these are not worth for everyone, I agree with you. I think we can skip those. Corinna
Re: [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS
On Oct 4 12:49, Ken Brown via Cygwin-patches wrote: > A successful connection can be indicated by STATUS_SUCCESS or > STATUS_PIPE_CONNECTED. THanks for catching but... huh? How does Windows generate two different status codes for the same result from the same function? Corinna
Re: [PATCH v2 0/6] Some AF_UNIX fixes
On Oct 4 12:49, Ken Brown via Cygwin-patches wrote: > I'm about to push these. Corinna, please check them when you return. > The only difference between v2 and v1 is that there are a few more > fixes. > > I'm trying to help get the AF_UNIX development going again. I'm > mostly working on the topic/af_unix branch. But when I find bugs that > exist on master, I'll push those to master and then merge master to > topic/af_unix. > > So far what I have on that branch locally (to be pushed shortly) is an > implementation of fhandler_socket_unix::read, which I've tested by > running the srver/client programs from Section 57.2 of Kerrisk's book, > "The Linux Programming Interface". Oh boy, this is S great! Thanks for working on that! Corinna
Re: [PATCH] Cygwin: winlean.h: remove most of extended memory API
On Sep 24 15:04, Jon Turney wrote: > On 24/09/2020 00:52, Ken Brown via Cygwin-patches wrote: > > This was added as a temporary measure in commit e18f7f99 because it > > wasn't yet in the mingw-w64 headers. With one exception, it is now in > > the current release of the headers (version 8.0.0), so we don't need > > it in winlean.h. The exception is that VirtualAlloc2 is only declared > > conditionally in , so retain it in winlean.h. Add > > I assume it's conditional on the windows version targetted, but it might > help to mention that in a comment. > > > "WINAPI" to its declaration for consistency with the delaration in > > memoryapi.h. > > > > Also revert commit 3d136011, which was a related temporary workaround. > > Looks good to me. > > I think this isn't going work any more with older win32api, but we probably > don't care about that. It would perhaps be nice to explicitly complain > about that (checking __MINGW64_VERSION_MAJOR somehow), rather than exploding > incomprehensibly if the w32api is too old? > > > In particular, I'd like to know if my handling of the declaration of > > VirtualAlloc2 seems reasonable. Among other things, I'm puzzled by the > > apparent need to add WINAPI. If it's really needed, I don't know how > > the calls of that function could have worked before. Can anyone > > enlighten me? > > I believe that WINAPI only does something (stdcall) on x86, so it might well > be that it's never worked on Windows 10 =>1803 x86? VirtualAlloc2 is only called in x86_64 code, so the WINAPI was not required. x86 is a lost case in terms of memory allocation anyway. Corinna
[ITA] po4a
Hi, I would like to adopt orphaned package po4a. https://po4a.org/ best regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/
