Question with the difference in shm_info between Linux and Cygwin

[Kun Yang via Cygwin]

Greetings,

I attempted to get the information about shared memory. Then I noticed some
difference in shm_info. I have some question about it.

Firstly, I would like to know is there any reason why shm_rss and shm_swp
doesn't exist? And how to get them? Additionally, is shm_atts the same as
shm_rss?

I would also like to inquire if swap_attempts and swap_successes the same in
Linux and Cygwin, always being zero and unused?

I would appreciate it if you could offer some related information.

Best Regards,
Yang Kun

-- 
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: util-linux-2.39.3-1: libblkid returns invalid physical_sector_size

[Mark Geisert via Cygwin]

On 4/2/2024 9:50 AM, Christian Franke via Cygwin wrote:

Christian Franke via Cygwin wrote:

,,,
BTW, according to the Linux kernel sources, BLKPBSZGET etc return 
'unsigned int' and not 'unsigned long' since first appearance in 
2.6.32-rc3 (2009?):


https://elixir.bootlin.com/linux/v2.6.32-rc3/source/block/ioctl.c#L276
https://elixir.bootlin.com/linux/v2.6.32-rc3/source/block/compat_ioctl.c#L743
https://elixir.bootlin.com/linux/v6.8.2/source/block/ioctl.c#L533

So I don't understand why the mentioned code would be correct for Linux.



It is likely an upstream regression from an 1+ year old commit. I filed 
a GH issue:

https://github.com/util-linux/util-linux/issues/2904


Thank you Christian for reporting the issue upstream.  I won't be able 
to try out the proposed fix in that issue 2904 as I'm about to be AFK 
for two weeks plus.  I will check in upon my return to keyboard.

Cheers & Regards,

..mark


--
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: util-linux-2.39.3-1: libblkid returns invalid physical_sector_size

[Christian Franke via Cygwin]

Christian Franke via Cygwin wrote:

,,,
BTW, according to the Linux kernel sources, BLKPBSZGET etc return 
'unsigned int' and not 'unsigned long' since first appearance in 
2.6.32-rc3 (2009?):


https://elixir.bootlin.com/linux/v2.6.32-rc3/source/block/ioctl.c#L276
https://elixir.bootlin.com/linux/v2.6.32-rc3/source/block/compat_ioctl.c#L743 


https://elixir.bootlin.com/linux/v6.8.2/source/block/ioctl.c#L533

So I don't understand why the mentioned code would be correct for Linux.



It is likely an upstream regression from an 1+ year old commit. I filed 
a GH issue:

https://github.com/util-linux/util-linux/issues/2904


--
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: util-linux-2.39.3-1: libblkid returns invalid physical_sector_size

[Christian Franke via Cygwin]

Bruce Jerrick via Cygwin wrote:

Downgrading to util-linux-2.33.3-3 does not help. The related code
differs, but has the same problem.


I take that back. The above should read "util-linux-2.33.1-3".



But it was OK in util-linux-2.33.1-3 .


Yes, this is correct. I possibly downgraded util-linux, but forgot 
libblkid1.



--
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: util-linux-2.39.3-1: libblkid returns invalid physical_sector_size

[Bruce Jerrick via Cygwin]

> Downgrading to util-linux-2.33.3-3 does not help. The related code
> differs, but has the same problem.

But it was OK in util-linux-2.33.1-3 .  The only difference in output
between that and the fixed 2.39.3-2 is that the latter includes one more
decimal place in the reported "human" sizes (GiB, TiB), which is very
welcome.


-- 
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: util-linux-2.39.3-1: libblkid returns invalid physical_sector_size

[Christian Franke via Cygwin]

Hi Mark,

Mark Geisert via Cygwin wrote:

Hi Christian,

On 3/31/2024 1:11 AM, Christian Franke via Cygwin wrote:

Testcase:

# cygcheck -f /sbin/fdisk.exe
util-linux-2.39.3-1

# /sbin/fdisk.exe -l /dev/sdd
Disk /dev/sdd: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 34359738880 bytes
I/O size (minimum/optimal): 34359738880 bytes / 34359738880 bytes

[...valuable investigation and patch suggestion elided...]

Your suggested patch looks fine to me.  I have added it to the patch 
deck for a new util-linux 2.39.3-2, which has just been uploaded.  The 
patch allows fdisk.exe to report the three correct values in my 
limited testing.

Thanks for the report and the patch!


You're welcome.

BTW, according to the Linux kernel sources, BLKPBSZGET etc return 
'unsigned int' and not 'unsigned long' since first appearance in 
2.6.32-rc3 (2009?):


https://elixir.bootlin.com/linux/v2.6.32-rc3/source/block/ioctl.c#L276
https://elixir.bootlin.com/linux/v2.6.32-rc3/source/block/compat_ioctl.c#L743
https://elixir.bootlin.com/linux/v6.8.2/source/block/ioctl.c#L533

So I don't understand why the mentioned code would be correct for Linux.


--
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: util-linux-2.39.3-1: libblkid returns invalid physical_sector_size

[Mark Geisert via Cygwin]

Hi Christian,

On 3/31/2024 1:11 AM, Christian Franke via Cygwin wrote:

Testcase:

# cygcheck -f /sbin/fdisk.exe
util-linux-2.39.3-1

# /sbin/fdisk.exe -l /dev/sdd
Disk /dev/sdd: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 34359738880 bytes
I/O size (minimum/optimal): 34359738880 bytes / 34359738880 bytes

[...valuable investigation and patch suggestion elided...]

Your suggested patch looks fine to me.  I have added it to the patch 
deck for a new util-linux 2.39.3-2, which has just been uploaded.  The 
patch allows fdisk.exe to report the three correct values in my limited 
testing.

Thanks for the report and the patch!

..mark


--
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: Linux xz issue

[Keith Thompson via Cygwin]

On Sun, Mar 31, 2024 at 9:15 PM Keith Thompson
 wrote:
>
> Achim Gratz strom...@nexgo.de wrote:
> > Beyond that, the version 5.4.6 that everybody is currently reverting to
> > (and is also still available for Cygwin if you want to go back) was
> > already released when the presumed bad actor was co-maintainer and their
> > involvement goes back even farther based on the Xz developer mailing
> > list.  The repository has been deactivated by GitHub so I can't check
> > there, but there is already some discussion about rolling back to 5.3.1
> > or thereabouts.
>
> The GitHub repo at  has been
> deactivated, but there's another xz repo (likely the original one)
> at .  The most recent commit
> in that repo is "CMake: Fix sabotaged Landlock sandbox check.".
>
> I have no inside knowledge about any of this.
>
> I'm running the Cygwin setup right now.  It reverts the xz package
> from 5.6.1-1 to 5.4.6-1.  Only 5.4.2-1 and 5.4.6-1 are available.

Sorry, I pasted the same link twice.

The deactivated GitHub repo is:
https://github.com/tukaani-project/xz

The tukaani.org repo (still active) is:
https://git.tukaani.org/xz.git

Thanks to oskar for pointing out my error.

-- 
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: Linux xz issue

[Keith Thompson via Cygwin]

Achim Gratz strom...@nexgo.de wrote:
> Beyond that, the version 5.4.6 that everybody is currently reverting to
> (and is also still available for Cygwin if you want to go back) was
> already released when the presumed bad actor was co-maintainer and their
> involvement goes back even farther based on the Xz developer mailing
> list.  The repository has been deactivated by GitHub so I can't check
> there, but there is already some discussion about rolling back to 5.3.1
> or thereabouts.

The GitHub repo at  has been
deactivated, but there's another xz repo (likely the original one)
at .  The most recent commit
in that repo is "CMake: Fix sabotaged Landlock sandbox check.".

I have no inside knowledge about any of this.

I'm running the Cygwin setup right now.  It reverts the xz package
from 5.6.1-1 to 5.4.6-1.  Only 5.4.2-1 and 5.4.6-1 are available.

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

util-linux-2.39.3-1: libblkid returns invalid physical_sector_size

[Christian Franke via Cygwin]

Testcase:

# cygcheck -f /sbin/fdisk.exe
util-linux-2.39.3-1

# /sbin/fdisk.exe -l /dev/sdd
Disk /dev/sdd: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 34359738880 bytes
I/O size (minimum/optimal): 34359738880 bytes / 34359738880 bytes
Disklabel type: dos
Disk identifier: 0x0ac1a23

Device Boot Start   End   Sectors   Size Id Type
/dev/sdd1    2048 976769023 976766976 465.8G  7 HPFS/NTFS/exFAT

Partition 1 does not start on physical sector boundary.

# printf '0x%016x\n' 34359738880
0x00080200


The problem is that libblkid expects the results of BLKIOMIN, BLKIOOPT 
and BLKPBSZGET as 64 bit 'unsigned long' but Cygwin only returns 32 bit 
'int':


- util-linux-2.39.3/libblkid/src/topology/ioctl.c:
...
static const struct topology_val {

    long  ioc;

    /* functions to set probing result */
    int (*set_ulong)(blkid_probe, unsigned long);
    int (*set_int)(blkid_probe, int);
    int (*set_u64)(blkid_probe, uint64_t);

} topology_vals[] = {
    { BLKALIGNOFF, NULL, blkid_topology_set_alignment_offset },
    { BLKIOMIN, blkid_topology_set_minimum_io_size },
    { BLKIOOPT, blkid_topology_set_optimal_io_size },
    { BLKPBSZGET, blkid_topology_set_physical_sector_size },
#ifdef BLKGETDISKSEQ
    { BLKGETDISKSEQ, .set_u64 = blkid_topology_set_diskseq },
#endif
    /* we read BLKSSZGET in topology.c */
};
...

- util-linux-2.39.3/libblkid/src/topology/topology.c:
...
struct blkid_struct_topology {
    unsigned long    alignment_offset;
    unsigned long    minimum_io_size;
    unsigned long    optimal_io_size;
    unsigned long    logical_sector_size;
    unsigned long    physical_sector_size;
    unsigned long   dax;
    uint64_t    diskseq;
};
...
int blkid_topology_set_physical_sector_size(blkid_probe pr, unsigned 
long val)

...

- newlib-cygwin/winsup/cygwin/fhandler/floppy.cc:
...
    case BLKIOMIN:
  debug_printf ("BLKIOMIN");
  *(int *)buf = (int) bytes_per_sector;
  break;
    case BLKIOOPT:
  debug_printf ("BLKIOOPT");
  *(int *)buf = (int) bytes_per_sector;
  break;
    case BLKPBSZGET:
  debug_printf ("BLKPBSZGET");
  *(int *)buf = (int) bytes_per_sector;
  break;
...


A quick fix which only works on LE platforms:

- util-linux-2.39.3/libblkid/src/topology/ioctl.c:
...
static int probe_ioctl_tp(blkid_probe pr,
...
        union {
            unsigned long ul;
            int i;
            uint64_t u64;
-        } data;
+        } data = { 0 };
...


Downgrading to util-linux-2.33.3-3 does not help. The related code 
differs, but has the same problem.


The fdisk variant in busybox-1.36.1-2 is not affected.

--
Regards,
Christian


--
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: Linux xz issue

[Achim Gratz via Cygwin]

Am 29.03.2024 um 23:43 schrieb Ron Murray via Cygwin:
There is a serious security issue with xz (and liblzma) versions 5.6.0-1 
and 5.6.1-1. I note that cywin currently is suggesting an upgrade to 
5.6.1-1, which is unsafe. I've looked at the cygwin archives and I don't 
see a reference to this: sorry if you're already aware of this issue.


Based on what I know so far (and I can't check in detail right now) 
Cygwin is likely not affected: it isn't Linux, nor does it use glibc or 
systemd and also not the patch for OpenSSH that allows the backdoor to 
get activated.  So, the code injection into liblzma5 has very likely not 
been performed during the build (I will check that, but it will take a 
week or so) and even if it did it could not work on Cygwin.


Beyond that, the version 5.4.6 that everybody is currently reverting to 
(and is also still available for Cygwin if you want to go back) was 
already released when the presumed bad actor was co-maintainer and their 
involvement goes back even farther based on the Xz developer mailing 
list.  The repository has been deactivated by GitHub so I can't check 
there, but there is already some discussion about rolling back to 5.3.1 
or thereabouts.


Please note that the account in question has also landed some code in 
libarchive which is likely going to get reverted.  From the looks of it 
there were a few sock-puppet accounts that were supporting the 
activities and it remains to be seen where else these might turn up.


--
Achim.

(on the road :-)



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

Linux xz issue

[Ron Murray via Cygwin]

There is a serious security issue with xz (and liblzma) versions 5.6.0-1 
and 5.6.1-1. I note that cywin currently is suggesting an upgrade to 
5.6.1-1, which is unsafe. I've looked at the cygwin archives and I don't 
see a reference to this: sorry if you're already aware of this issue.


References:
https://www.cisa.gov/news-events/alerts/2024/03/29/reported-supply-chain-compromise-affecting-xz-utils-data-compression-library-cve-2024-3094
https://access.redhat.com/security/cve/CVE-2024-3094
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3094
https://sysdig.com/blog/cve-2024-3094-detecting-the-sshd-backdoor-in-xz-utils/

Thanks,

 .Ron

--
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761

--
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: ntfs-3g/ntfssecaudit build failed with fatal error: linux/fd.h: No such file or directory

[Brian Inglis via Cygwin]

On 2024-03-24 12:59, Matthias--- via Cygwin wrote:

I downloaded ntfs-3g_ntfsprogs-2022.10.3.tgz from tuxera, extract it and run, 
in my cygwin 3.5
environment:
./configure
make ntfsprogs

I got a "fatal error: linux/fd.h: No such file or directory".
All ntfsprogs are build in ~/ntfsprogs but not ntfsrecover, ntfssecaudit and 
ntfsusermap.

So do you have any hint where I can find this "linux/fd.h" ?


On Linux!

Check your config and make logs for questionable defaults or automatic 
selections.

You may want to first try just `make`, to ensure that all subdirectory configs 
are done properly, as those are often run by the top level make, using the 
cached results from configure.


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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

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

ntfs-3g/ntfssecaudit build failed with fatal error: linux/fd.h: No such file or directory

[Matthias--- via Cygwin]

Hello,


I downloaded ntfs-3g_ntfsprogs-2022.10.3.tgz from tuxera, extract it and run, 
in my cygwin 3.5
environment:
   ./configure
   make ntfsprogs


I got a "fatal error: linux/fd.h: No such file or directory".
All ntfsprogs are build in ~/ntfsprogs but not ntfsrecover, ntfssecaudit and 
ntfsusermap.

So do you have any hint where I can find this "linux/fd.h" ?

Thanks in advance
Matthias


-- 
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: util-linux 2.39.3-1 (test)

[Mark Geisert via Cygwin]

The following packages have been uploaded to the Cygwin distribution:

* util-linux-2.39.3-1
* util-linux-debuginfo-2.39.3-1
* libblkid-devel-2.39.3-1
* libblkid1-2.39.3-1
* libfdisk-devel-2.39.3-1
* libfdisk1-2.39.3-1
* libsmartcols-devel-2.39.3-1
* libsmartcols1-2.39.3-1
* libuuid-devel-2.39.3-1
* libuuid1-2.39.3-1
* uuidd-2.39.3-1

This brings Cygwin's util-linux up to a recent version that many Linux 
distributions still package.


I would appreciate feedback from any users who can install this test 
version and make sure fallocate, more, script, whereis, rename, or any of 
the other programs that make up the util-linux package work properly. 
Thank you,


..mark

--
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: Can util-linux 2.33.1-3 come out of [test] ?

[Mark Geisert via Cygwin]

On 2/2/2024 3:52 AM, Bruce Jerrick via Cygwin wrote:

util-linux 2.33.1-3 depends on cygwin >= 3.5.0 .  The latter has come
out of test, so can util-linux 2.33.1-3 also come out of test?


Done. Note that this means if you select util-linux 2.33.1-3 for 
installation, your Cygwin version will also be upgraded to 3.5.0 unless 
you take measures to prevent it in your setup interactions.


..mark


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

Can util-linux 2.33.1-3 come out of [test] ?

[Bruce Jerrick via Cygwin]

util-linux 2.33.1-3 depends on cygwin >= 3.5.0 .  The latter has come
out of test, so can util-linux 2.33.1-3 also come out of test?

-- 
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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Mark Geisert via Cygwin]

On 1/27/2024 7:47 AM, Marco Atzeri via Cygwin wrote:

On 27/01/2024 11:06, Mark Geisert via Cygwin wrote:

On 1/26/2024 11:26 PM, ASSI via Cygwin wrote:

Mark Geisert via Cygwin writes:

A new build of the util-linux package, 2.33.1-3, now includes
fallocate and its man page.  The updated package is now making its way
to the Cygwin mirrors.  fallocate requires Cygwin version >= 3.5.0.


It also doesn't work at all on Cygwin 3.4.x and 3.5 isn't yet released,
so please add a dependency for cygwin(>= 3.5) to the hints file.


Done. I guess you answered my unasked question of how to limit one 
executable of a package to specific Cygwin version(s): you don't. You 
limit the whole package instead?

Thanks & Regards,

..mark



yes but put it as test, otherwise Setup will pull cygwin-3.5.0


Done. Thanks for the info Marco.

..mark


--
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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Marco Atzeri via Cygwin]

On 27/01/2024 11:06, Mark Geisert via Cygwin wrote:

On 1/26/2024 11:26 PM, ASSI via Cygwin wrote:

Mark Geisert via Cygwin writes:

A new build of the util-linux package, 2.33.1-3, now includes
fallocate and its man page.  The updated package is now making its way
to the Cygwin mirrors.  fallocate requires Cygwin version >= 3.5.0.


It also doesn't work at all on Cygwin 3.4.x and 3.5 isn't yet released,
so please add a dependency for cygwin(>= 3.5) to the hints file.


Done. I guess you answered my unasked question of how to limit one 
executable of a package to specific Cygwin version(s): you don't. You 
limit the whole package instead?

Thanks & Regards,

..mark



yes but put it as test, otherwise Setup will pull cygwin-3.5.0



--
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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Mark Geisert via Cygwin]

On 1/26/2024 11:26 PM, ASSI via Cygwin wrote:

Mark Geisert via Cygwin writes:

A new build of the util-linux package, 2.33.1-3, now includes
fallocate and its man page.  The updated package is now making its way
to the Cygwin mirrors.  fallocate requires Cygwin version >= 3.5.0.


It also doesn't work at all on Cygwin 3.4.x and 3.5 isn't yet released,
so please add a dependency for cygwin(>= 3.5) to the hints file.


Done. I guess you answered my unasked question of how to limit one 
executable of a package to specific Cygwin version(s): you don't. You 
limit the whole package instead?

Thanks & Regards,

..mark


--
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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[ASSI via Cygwin]

Mark Geisert via Cygwin writes:
> A new build of the util-linux package, 2.33.1-3, now includes
> fallocate and its man page.  The updated package is now making its way
> to the Cygwin mirrors.  fallocate requires Cygwin version >= 3.5.0.

It also doesn't work at all on Cygwin 3.4.x and 3.5 isn't yet released,
so please add a dependency for cygwin(>= 3.5) to the hints file.


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

-- 
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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Cedric Blancher via Cygwin]

On Thu, 25 Jan 2024 at 10:37, Cedric Blancher  wrote:
>
> On Thu, 25 Jan 2024 at 04:53, Mark Geisert via Cygwin  
> wrote:
> >
> > On 1/23/2024 4:41 PM, Mark Geisert via Cygwin wrote:
> > > On 1/23/2024 3:36 AM, Roland Mainz via Cygwin wrote:
> > >> Small bug report:
> > >> Cygwin 3.5. now has support for SEEK_HOLE (thanks! :-) ), but
> > >> /usr/bin/fallocate is still missing in the "util-linux" package.
> > >>
> > >> Can someone please enable that tool ?
> > >
> > > I'll look into this.
> >
> > A new build of the util-linux package, 2.33.1-3, now includes fallocate
> > and its man page.  The updated package is now making its way to the
> > Cygwin mirrors.  fallocate requires Cygwin version >= 3.5.0.
>
> Thank you.
>
> The GNU coreutils package (cp, mv), GNU tar (tar), pax (pax) and
> libarchive packages need to be rebuild, as they all support SEEK_HOLE.
>
> @Corinna Vinschen Could you please include these updated packages as
> 'sparse file aware', as they support SEEK_HOLE?

... Include in the Cygwin 3.5 release notes. My fault, I hit the send
button too fast

Ced
-- 
Cedric Blancher 
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

-- 
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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Cedric Blancher via Cygwin]

On Thu, 25 Jan 2024 at 04:53, Mark Geisert via Cygwin  wrote:
>
> On 1/23/2024 4:41 PM, Mark Geisert via Cygwin wrote:
> > On 1/23/2024 3:36 AM, Roland Mainz via Cygwin wrote:
> >> Small bug report:
> >> Cygwin 3.5. now has support for SEEK_HOLE (thanks! :-) ), but
> >> /usr/bin/fallocate is still missing in the "util-linux" package.
> >>
> >> Can someone please enable that tool ?
> >
> > I'll look into this.
>
> A new build of the util-linux package, 2.33.1-3, now includes fallocate
> and its man page.  The updated package is now making its way to the
> Cygwin mirrors.  fallocate requires Cygwin version >= 3.5.0.

Thank you.

The GNU coreutils package (cp, mv), GNU tar (tar), pax (pax) and
libarchive packages need to be rebuild, as they all support SEEK_HOLE.

@Corinna Vinschen Could you please include these updated packages as
'sparse file aware', as they support SEEK_HOLE?

Ced
-- 
Cedric Blancher 
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

-- 
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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Mark Geisert via Cygwin]

On 1/23/2024 4:41 PM, Mark Geisert via Cygwin wrote:

On 1/23/2024 3:36 AM, Roland Mainz via Cygwin wrote:

Small bug report:
Cygwin 3.5. now has support for SEEK_HOLE (thanks! :-) ), but
/usr/bin/fallocate is still missing in the "util-linux" package.

Can someone please enable that tool ?


I'll look into this.


A new build of the util-linux package, 2.33.1-3, now includes fallocate 
and its man page.  The updated package is now making its way to the 
Cygwin mirrors.  fallocate requires Cygwin version >= 3.5.0.

Enjoy,

..mark


--
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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Cedric Blancher via Cygwin]

On Wed, 24 Jan 2024 at 07:33, Cedric Blancher  wrote:
>
> On Tue, 23 Jan 2024 at 12:37, Roland Mainz via Cygwin  
> wrote:
> >
> > Hi!
> >
> > -
> >
> > Small bug report:
> > Cygwin 3.5. now has support for SEEK_HOLE (thanks! :-) ), but
> > /usr/bin/fallocate is still missing in the "util-linux" package.
> >
> > Can someone please enable that tool ?
>
> Good catch!
>
> @Corinna Vinschen
> Does /usr/bin/cp in Cygwin copy holes correctly?

cp, mv, tar, pax must be sparse file aware. Also Schilly star.
Plus /usr/bin/fallocate

Anything else?

Ced
-- 
Cedric Blancher 
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

-- 
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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Sam Edge via Cygwin]

On 24/01/2024 06:33, Cedric Blancher via Cygwin wrote:
> Does /usr/bin/cp in Cygwin copy holes correctly

Yesterday, within the 'ware,
I saw some bytes that weren't there!
They weren't there again today,
They'd better not just go away.

--
Sam Edge
(with apologies to Willian Hughes Mearns)



OpenPGP_0x8AC2CEBF54528E30.asc
Description: OpenPGP public key


OpenPGP_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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Cedric Blancher via Cygwin]

On Tue, 23 Jan 2024 at 12:37, Roland Mainz via Cygwin  wrote:
>
> Hi!
>
> -
>
> Small bug report:
> Cygwin 3.5. now has support for SEEK_HOLE (thanks! :-) ), but
> /usr/bin/fallocate is still missing in the "util-linux" package.
>
> Can someone please enable that tool ?

Good catch!

@Corinna Vinschen
Does /usr/bin/cp in Cygwin copy holes correctly?

Ced
-- 
Cedric Blancher 
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

-- 
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: /usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Mark Geisert via Cygwin]

On 1/23/2024 3:36 AM, Roland Mainz via Cygwin wrote:

Small bug report:
Cygwin 3.5. now has support for SEEK_HOLE (thanks! :-) ), but
/usr/bin/fallocate is still missing in the "util-linux" package.

Can someone please enable that tool ?


I'll look into this.

..mark


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

/usr/bin/fallocate missing in Cygwin 3.5's "util-linux" ...

[Roland Mainz via Cygwin]

Hi!

-

Small bug report:
Cygwin 3.5. now has support for SEEK_HOLE (thanks! :-) ), but
/usr/bin/fallocate is still missing in the "util-linux" package.

Can someone please enable that tool ?



Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

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

docker container for building cygwin on Linux

[Johannes Thoma via Cygwin]

Hi list,

I just published a docker image with all the necessary build dependencies 
(except
for dumper.exe) for building cygwin. We are using it to compile our WinDRBD 
driver
and with a few additional packages it was possible to compile cygwin 
(newlib-cygwin)
as well.

This is how to obtain it:

docker pull quay.io/johannesthoma/windrbd-devenv-cygwin

To build the container yourself you can use the

make docker-cygwin

command of the WinDRBD driver (https://github.com/LINBIT/WinDRBD) (you have
to use the windrbd-1.2 branch). Since this takes an hour to complete (2 
C-compilers
being built) I recommend to use the quay.io image.

There is one thing about the container which is a little bit how do I say -
not so clean - we import the cygwin-gcc compiler from Fedora 38 packages
in a Ubuntu 22.04 - from
https://download.copr.fedorainfracloud.org/results/yselkowitz/cygwin/
I don't know if yselkowitz is on the cygwin list but it would be helpful
to have maybe a script to build those packages, so if someone could
share some hints how to build the cygwin compilers that would be
of great help.

In case you are not familiar with docker here's what I use:

docker tag quay.io/johannesthoma/windrbd-devenv-cygwin windrbd-devenv-cygwin
docker run -v /home/johannes/cygwin-sources-new:/cygwin-sources --name 
build-cygwin-new -d windrbd-devenv-cygwin tail -f /dev/null
docker exec -it build-cygwin-new bash

From there everything in newlib-cygwin (except for dumper so configure winsup
with --disable-dumper) should be buildable.

If you find this container useful, have questions or feature requests or find 
bugs
or things not working as expected, please let me know.

Best regards,

 - Johannes

--
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: man-pages-linux 6.05.01

[Cygwin Linux Man Pages Maintainer via Cygwin-announce via Cygwin]

The following package has been upgraded in the Cygwin distribution:

* man-pages-linux   6.05.01

Documents the Linux kernel system calls and C library interfaces used
by programs, plus system and administrative utilities, devices, file
system, file, and data formats, and related information.

For more information, see the project home page:

https://kernel.org/doc/man-pages/

As Cygwin has its own man pages with some conflicts, these man pages are
installed under /usr/share/man/man-pages-linux/, so by default searching
or viewing these pages requires the option:

$ apropos -m|--systems man-pages-linux ...
$ man -m|--systems man-pages-linux ...

Cygwin man pages are under the default system "man", so for convenience
both systems may be specified separated by comma e.g.

$ man -m man,man-pages-linux ...

The path or option may also be added explicitly to a users MANPATH or
alias e.g.

$ export MANPATH=$MANPATH:/usr/share/man/man-pages-linux

$ alias apropos='apropos -m man,man-pages-linux'
$ alias man='man -m man,man-pages-linux'

Add -a to show both Cygwin and Linux (and POSIX if companion package
man-pages-posix is also installed) manual pages.

For convenience and backward compatibility /usr/share/man/linux is
provided as a symlink. 

If you prefer to see Linux man pages over Cygwin man pages, then use
-m|--systems linux in the examples above, or add -m linux to a command.

Release 6 added some section 2 and 3 pages suffixed by const, head,
or type installed in the base section directories.

For recent changes, please see below, or after installation read
/usr/share/doc/man-pages-linux/Changes:


man-pages   6.05.01 2023-08-01

New and rewritten pages

- man2/ ioctl_pipe.2
- man3/ regex.3
- man5/ erofs.5

Newly documented interfaces in existing pages

- bpf.2 EAGAIN
- ioctl_userfaultfd.2   UFFD_FEATURE_EXACT_ADDRESS
- prctl.2   PR_GET_AUXV
- recv.2MSG_CMSG_CLOEXEC
- statx.2   STAT_ATTR_MOUNT_ROOT
- syscall.2 ENOSYS
- resolv.conf.5 no-
RES_NO
- tmpfs.5   CONFIG_TRANSPARENT_HUGEPAGE
- ip.7  IP_LOCAL_PORT_RANGE
- rtnetlink.7   IFLA_PERM_ADDRESS

New and changed links

- man3type/
regex_t.3type   (regex(3))
regmatch_t.3type(regex(3))
regoff_t.3type  (regex(3))

Global changes

-  Types:
   -  Document functions using off64_t as if they used off_t (except
  for lseek64()).

-  Formatting:
   -  use `\%`
   -  un-bracket tbl(1) tables

-  Licenses:
   -  Relicense ddp.7 from VERBATIM_ONE_PARA to Linux-man-pages-copyleft.
   -  Relicense dir_colors.5 from LDPv1 to GPL-2.0-or-later.
   -  Use new SPDX license identifiers:
  -  Linux-man-pages-1-para (was VERBATIM_ONE_PARA)
  -  Linux-man-pages-copyleft-2-para(was VERBATIM_TWO_PARA)
  -  Linux-man-pages-copyleft-var   (was VERBATIM_PROF)

-  Build system:
   -  Ignore dot-dirs within $MANDIR(6.05.01)
   -  Keep file modes in the release tarball.
   -  Fix symlink installation (`make install LINK_PAGES=symlink`).
   -  Add support for using bzip2(1), lzip(1), and xz(1) when installing
  pages and creating release tarballs.
   -  Create reproducible release tarballs.
   -  Move makefiles from lib/ to share/mk/.
   -  Support mdoc(7) pages.
   -  Relicense Makefiles as GPL-3.0-or-later.
   -  Build PostScript and PDF manual pages.
   -  Add support for running our build system on arbitrary source
  trees; this makes it possible to easily run our linters on another
  project's manual pages as easily as `make lint MANDIR=~/src/groff`

Changes to individual pages

- The manual pages (and other files in the repository) have been
  improved beyond what this changelog covers. To learn more about
  changes applied to individual pages, use git(1).


-- 
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: renameat2 works differently than on Linux

[Corinna Vinschen via Cygwin]

Hi Bruno,

On Apr 18 14:47, Bruno Haible via Cygwin wrote:
> Hi,
> 
> The renameat2 function is "Linux-specific", says the man page [1]; however,
> Cygwin implements it as well.
> 
> In Cygwin 3.4.6, in a specific case, it operates differently than the
> Linux function. Namely, if the old* arguments and the new* arguments
> are the same and the flag RENAME_NOREPLACE is specified.
> [...]
> Output on Linux (glibc, musl libc):
> ret=-1, errno=17=EEXIST
> 
> Output on Cygwin 3.4.6:
> ret=0
> 
> Note that there is some ambiguity about this case in [1]: One one hand,
> there is the general statement about rename():
>   "If oldpath and newpath are existing hard links referring to the
>same file, then rename() does nothing, and returns a success status."
> On the other hand, the text regarding RENAME_NOREPLACE says:
>   "Return an error if newpath already exists."

Thanks for the testcase.  I guess the ambiguity doesn't matter, given
it's a Linux function anyway.  It makes sense to behave the same, if
possible.

I pushed a patch.  The next test release cygwin-3.5.0-0.284.gd30a5917a9c4
will contain the patch for testing.


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

renameat2 works differently than on Linux

[Bruno Haible via Cygwin]

Hi,

The renameat2 function is "Linux-specific", says the man page [1]; however,
Cygwin implements it as well.

In Cygwin 3.4.6, in a specific case, it operates differently than the
Linux function. Namely, if the old* arguments and the new* arguments
are the same and the flag RENAME_NOREPLACE is specified.

How to reproduce:
 foo.c 
#ifdef __CYGWIN__
 #include 
#else
 #define _GNU_SOURCE 1
 #ifdef __linux__
 # include 
 #endif
#endif
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int
main (void)
{
  system ("rm -rf sub2");
  int dfd = open (".", O_RDONLY);
  if (dfd < 0) perror ("open");
  int ret = mkdir ("sub2", 0700);
  if (ret < 0) perror ("mkdir");
  close (creat ("sub2/file", 0600));
#if defined __CYGWIN__ || defined __GLIBC__
  ret = renameat2 (dfd, "sub2/file", dfd, "sub2/file", RENAME_NOREPLACE);
#else /* musl libc */
  ret = syscall (SYS_renameat2, dfd, "sub2/file", dfd, "sub2/file", 1);
#endif
  if (ret >= 0)
printf ("ret=%d\n", ret);
  else
printf ("ret=%d, errno=%d%s\n", ret, errno, errno == EEXIST ? "=EEXIST" : 
"");
}
===
Output on Linux (glibc, musl libc):
ret=-1, errno=17=EEXIST

Output on Cygwin 3.4.6:
ret=0

Note that there is some ambiguity about this case in [1]: One one hand,
there is the general statement about rename():
  "If oldpath and newpath are existing hard links referring to the
   same file, then rename() does nothing, and returns a success status."
On the other hand, the text regarding RENAME_NOREPLACE says:
  "Return an error if newpath already exists."

Bruno

[1] https://man7.org/linux/man-pages/man2/rename.2.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] Updated: man-pages-linux 6.04

[Cygwin Linux Man Pages Maintainer via Cygwin-announce via Cygwin]

The following package has been upgraded in the Cygwin distribution:

* man-pages-linux   6.04

Documents the Linux kernel system calls and C library interfaces used
by programs, plus system and administrative utilities, devices, file
system, file, and data formats, and related information.

For more information, see the project home page:

https://kernel.org/doc/man-pages/

As Cygwin has its own man pages with some conflicts, these man pages are
installed under /usr/share/man/man-pages-linux/, so by default searching
or viewing these pages requires the option:

$ apropos -m|--systems man-pages-linux ...
$ man -m|--systems man-pages-linux ...

Cygwin man pages are under the default system "man", so for convenience
both systems may be specified separated by comma e.g.

$ man -m man,man-pages-linux ...

The path or option may also be added explicitly to a users MANPATH or
alias e.g.

$ export MANPATH=$MANPATH:/usr/share/man/man-pages-linux

$ alias apropos='apropos -m man,man-pages-linux'
$ alias man='man -m man,man-pages-linux'

Add -a to show both Cygwin and Linux (and POSIX if companion package
man-pages-posix is also installed) manual pages.

For convenience and backward compatibility /usr/share/man/linux is
provided as a symlink. 

If you prefer to see Linux man pages over Cygwin man pages, then use
-m|--systems linux in the examples above, or add -m linux to a command.

Release 6 added some section 2 and 3 pages suffixed by const, head,
or type installed in the base section directories.

For recent changes, please see below, or after installation read
/usr/share/doc/man-pages-linux/Changes:


man-pages-6.04  2023-04-03

Newly documented interfaces in existing pages

* proc.5- KPF_PGTABLE   (Linux 4.18)
* landlock.7- LANDLOCK_ACCESS_FS_REFER  (Linux 5.19)
* udp.7 - UDP_GRO   (Linux 5.0)
- UDP_SEGMENT   (Linux 4.18)

Global changes

*  Sections:
   -  Add HISTORY.
   -  HISTORY: Restore C89 references.
   -  Repurpose VERSIONS.
   -  Simplify STANDARDS.
   -  SYNOPSIS: Mark several functions as deprecated.

*  Build system:
   -  Support installing in different mandirs
  (e.g., man3typedir='/usr/share/man/man3').
   -  Support installing compressed pages (Z='.gz').
   -  Support installing link pages as symlinks (LINK_PAGES='symlink').

Changes to individual pages

The manual pages (and other files in the repository) have been improved
beyond what this changelog covers.  To learn more about changes applied
to individual pages, use git(1).


-- 
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: newlocale: Linux incompatibility

[Corinna Vinschen via Cygwin]

On Mar 25 13:03, Brian Inglis via Cygwin wrote:
> On 2023-03-25 05:49, Corinna Vinschen via Cygwin wrote:
> It looks like /proc/locales contains the same content as produced by locale 
> -a?

Yes, locale -a actually opens /proc/locales to read the locales from the
Cygwin core, just as it opens /proc/codesets to implement locale -m.
The idea was to have these definitions collected inside the DLL instead
of having to duplicate code in an external tool.


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: newlocale: Linux incompatibility

[Corinna Vinschen via Cygwin]

On Mar 25 13:03, Brian Inglis via Cygwin wrote:
> On 2023-03-25 05:49, Corinna Vinschen via Cygwin wrote:
> > On Mar 24 16:49, Brian Inglis via Cygwin wrote:
> > I never heard about an environment variable called LANGUAGE.  This is
> > about LANG/LC_ALL/LC_whatever, so POSIX syntax is required...
> 
> Used by gettext:
> 
> https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html

Ok, I'm not using that because I didn't even know that.  But I'm not
sure why you even mention it, it has nothing to do with Cygwin's
locale implementation which is based on the POSIX definitions.
Exception here is where the data comes from since we don't maintain
locale definition files and thus we don't follow
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html
to the letter.

> > > Aha - a nice new 3.5.0 feature - as well as /proc/codesets - is that
> > > charsets e.g. ISO-10646, etc. rather than encodings e.g. UTF-8, etc.!
> 
> > It's a list of what you can use as codeset in $LANG and friends as in
> >LC_CTYPE=lang_TERRITORY.codeset@modifier
> 
> You are using codeset to mean encoding, whereas in Unicode and W3 it usually
> means coded character set/charset; it can also mean charmap; see iconv(1):

I'm using the POSIX definition here.  Codeset is codeset, as in
https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

Quote:

  If the locale value has the form:

  language[_territory][.codeset]

  it refers to an implementation-provided locale, where settings of
  language, territory, and codeset are implementation-defined.

So I'm using the name "codesets" to follow POSIX documentation for
setting the matching locale environment variables, exactly to avoid
confusion.


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: newlocale: Linux incompatibility

[Brian Inglis via Cygwin]

On 2023-03-25 05:49, Corinna Vinschen via Cygwin wrote:

On Mar 24 16:49, Brian Inglis via Cygwin wrote:

On 2023-03-24 06:18, Corinna Vinschen via Cygwin wrote:

First, it's a bug in the Emacs testsuite.  The test simply assumes that
there's no en_DE locale on any system, but that's just not true.
Windows support the RFC 5646 locale "en-DE", which is called "English
(Germany)" in the "Region" settings.
You can also check with `locale -av | less' and search for en_DE.
For the reminder of this mail, I assume you're talking about Cygwin 3.5.
I won't fix this for 3.4 anymore, given how much locale handling has
changed for 3.5.
The second bug is that Cygwin blindly trusts the Windows function
ResolveLocaleName().  That function blatantly converts even vaguely
similar locales into something it supports.  E.g., it converts "en-XY"
to "en-US".  I. .e., even if you use "en_XY.utf8" as locale, the above
testcase will wrongly succeed.  So I have to rethink how I resolve POSIX
locales to Windows locales.



Does Windows even consider https://www.rfc-editor.org/rfc/rfc4647 "Matching
of Language Tags", part of https://www.rfc-editor.org/info/bcp47 "Language
Tags", and if POSIX only matches exactly, will LANGUAGE be able to be used
for fallback?



I never heard about an environment variable called LANGUAGE.  This is
about LANG/LC_ALL/LC_whatever, so POSIX syntax is required...


Used by gettext:

https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html

also LINGUAS FYI controlling, documentating, or limiting translations:

https://www.gnu.org/software/gettext/manual/html_node/po_002fLINGUAS.html
https://www.gnu.org/software/gettext/manual/html_node/Installers.html

as POSIX punts a lot of locale handling into the (hand waving) implementation 
defined bucket, where this is the primary implementation.



I currently define LANGUAGE=en_CA:en_GB:en in case en-CA is unsupported by
anything.
[I use my own en-CA locale not the glibc default created by https://rap.dk/.]
Will "-" be supported like "_" as a separator in values?



In Cygwin?  No.  The POSIX syntax is required, it's converted into
a matching Windows RFC 5646 locale internally.



And the third bug is that Cygwin fails to set errno if it doesn't
support a locale, but that's a minor inconvenience in comparison.
Thanks for the report, I totally missed the above problem with
ResolveLocaleName.



I pushed a couple of patches which hopefully clean up the code.  It's
really frustrating how these Windows locale functions work.  Or, rather,
not work.  I mean, come on...
- ResolveLocaleName() resolves "ff-BF" to "ff-Latn-SN", not to
"ff-Adlm-BF" or "ff-Latn-BF", even though both exist.
- There's a locale called "sd-Arab-PK" and a locale "sd-Deva-IN".  If
you ask for the script used in "sd-IN", the result is "Arab", not
"Deva".
I had to create a replacement function for ResolveLocaleName which
doesn't return totally screwy and unexpected results, and special case
two more locales in /proc/locales output so the output makes sense.



Aha - a nice new 3.5.0 feature - as well as /proc/codesets - is that
charsets e.g. ISO-10646, etc. rather than encodings e.g. UTF-8, etc.!



It's a list of what you can use as codeset in $LANG and friends as in
   LC_CTYPE=lang_TERRITORY.codeset@modifier


You are using codeset to mean encoding, whereas in Unicode and W3 it usually 
means coded character set/charset; it can also mean charmap; see iconv(1):


https://pubs.opengroup.org/onlinepubs/9699919799/utilities/iconv.html

Further confused by codeset definition:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_99

linking to:

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html#tag_06_02

which says POSIX "provides no means of defining a wide-character codeset" 
implying encodings such as UCS-2/UTF-16 and UCS-4/UTF-32 can not be specified, 
requiring a non-POSIX approach to conversion.


Also IBM uses codeset to distinguish between EBCDIC and ASCII encodings.

Adding to the confusion ISO uses codeset to refer generically to each set of 
codes supported by each part of ISO-639-1/2/3/5, ISO-3166-1/2/3, and ISO-15924, 
as well as ISO-8859-1...16.


I get no hits from RFCs.

To avoid ambiguity and reduce possible confusion, it may be better to name this 
charmaps as used in locale(1), and produced by locale -m with the same apparent 
content?

It looks like /proc/locales contains the same content as produced by locale -a?

JM2c ;^>

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Document

Re: newlocale: Linux incompatibility

[Corinna Vinschen via Cygwin]

On Mar 24 16:49, Brian Inglis via Cygwin wrote:
> On 2023-03-24 06:18, Corinna Vinschen via Cygwin wrote:
> > > First, it's a bug in the Emacs testsuite.  The test simply assumes that
> > > there's no en_DE locale on any system, but that's just not true.
> > > Windows support the RFC 5646 locale "en-DE", which is called "English
> > > (Germany)" in the "Region" settings.
> > > 
> > > You can also check with `locale -av | less' and search for en_DE.
> > > 
> > > For the reminder of this mail, I assume you're talking about Cygwin 3.5.
> > > I won't fix this for 3.4 anymore, given how much locale handling has
> > > changed for 3.5.
> > > 
> > > The second bug is that Cygwin blindly trusts the Windows function
> > > ResolveLocaleName().  That function blatantly converts even vaguely
> > > similar locales into something it supports.  E.g., it converts "en-XY"
> > > to "en-US".  I. .e., even if you use "en_XY.utf8" as locale, the above
> > > testcase will wrongly succeed.  So I have to rethink how I resolve POSIX
> > > locales to Windows locales.
> 
> Does Windows even consider https://www.rfc-editor.org/rfc/rfc4647 "Matching
> of Language Tags", part of https://www.rfc-editor.org/info/bcp47 "Language
> Tags", and if POSIX only matches exactly, will LANGUAGE be able to be used
> for fallback?

I never heard about an environment variable called LANGUAGE.  This is
about LANG/LC_ALL/LC_whatever, so POSIX syntax is required...

> I currently define LANGUAGE=en_CA:en_GB:en in case en-CA is unsupported by
> anything.
> [I use my own en-CA locale not the glibc default created by https://rap.dk/.]
> 
> Will "-" be supported like "_" as a separator in values?

In Cygwin?  No.  The POSIX syntax is required, it's converted into
a matching Windows RFC 5646 locale internally.

> > > And the third bug is that Cygwin fails to set errno if it doesn't
> > > support a locale, but that's a minor inconvenience in comparison.
> > > 
> > > Thanks for the report, I totally missed the above problem with
> > > ResolveLocaleName.
> > 
> > I pushed a couple of patches which hopefully clean up the code.  It's
> > really frustrating how these Windows locale functions work.  Or, rather,
> > not work.  I mean, come on...
> > 
> > - ResolveLocaleName() resolves "ff-BF" to "ff-Latn-SN", not to
> >"ff-Adlm-BF" or "ff-Latn-BF", even though both exist.
> > 
> > - There's a locale called "sd-Arab-PK" and a locale "sd-Deva-IN".  If
> >you ask for the script used in "sd-IN", the result is "Arab", not
> >"Deva".
> >
> > I had to create a replacement function for ResolveLocaleName which
> > doesn't return totally screwy and unexpected results, and special case
> > two more locales in /proc/locales output so the output makes sense.
> 
> Aha - a nice new 3.5.0 feature - as well as /proc/codesets - is that
> charsets e.g. ISO-10646, etc. rather than encodings e.g. UTF-8, etc.!

It's a list of what you can use as codeset in $LANG and friends as in

  LC_CTYPE=lang_TERRITORY.codeset@modifier


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: newlocale: Linux incompatibility

[Brian Inglis via Cygwin]

On 2023-03-24 06:18, Corinna Vinschen via Cygwin wrote:

On Mar 23 22:14, Corinna Vinschen via Cygwin wrote:

On Mar 23 15:48, Ken Brown via Cygwin wrote:

I'm reporting this here rather than the newlib list because the behavior is
compatible with Posix but not Linux, so I think it's a Cygwin issue.


Actually, it's a Windows issue :)


Consider the following test case:

$ cat locale_test.c
#include 
#include 

int main ()
{
   const char *locale = "en_DE.UTF-8";
   locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK, locale, 0);
   if (!loc)
 perror ("newlocale");
   else
 printf ("newlocale succeeded on invalid locale %s\n", locale);
}

$ gcc -o locale_test locale_test.c

$ ./locale_test.exe
newlocale succeeded on invalid locale en_DE.UTF-8

On Linux, the newlocale call fails with ENOENT, as is documented on the man
page.  Posix doesn't say what should happen on an invalid locale, so this is
not, strictly speaking, a bug.


Three bugs in fact.

First, it's a bug in the Emacs testsuite.  The test simply assumes that
there's no en_DE locale on any system, but that's just not true.
Windows support the RFC 5646 locale "en-DE", which is called "English
(Germany)" in the "Region" settings.

You can also check with `locale -av | less' and search for en_DE.

For the reminder of this mail, I assume you're talking about Cygwin 3.5.
I won't fix this for 3.4 anymore, given how much locale handling has
changed for 3.5.

The second bug is that Cygwin blindly trusts the Windows function
ResolveLocaleName().  That function blatantly converts even vaguely
similar locales into something it supports.  E.g., it converts "en-XY"
to "en-US".  I. .e., even if you use "en_XY.utf8" as locale, the above
testcase will wrongly succeed.  So I have to rethink how I resolve POSIX
locales to Windows locales.


Does Windows even consider https://www.rfc-editor.org/rfc/rfc4647 "Matching of 
Language Tags", part of https://www.rfc-editor.org/info/bcp47 "Language Tags", 
and if POSIX only matches exactly, will LANGUAGE be able to be used for fallback?


I currently define LANGUAGE=en_CA:en_GB:en in case en-CA is unsupported by 
anything.

[I use my own en-CA locale not the glibc default created by https://rap.dk/.]

Will "-" be supported like "_" as a separator in values?


And the third bug is that Cygwin fails to set errno if it doesn't
support a locale, but that's a minor inconvenience in comparison.

Thanks for the report, I totally missed the above problem with
ResolveLocaleName.


I pushed a couple of patches which hopefully clean up the code.  It's
really frustrating how these Windows locale functions work.  Or, rather,
not work.  I mean, come on...

- ResolveLocaleName() resolves "ff-BF" to "ff-Latn-SN", not to
   "ff-Adlm-BF" or "ff-Latn-BF", even though both exist.

- There's a locale called "sd-Arab-PK" and a locale "sd-Deva-IN".  If
   you ask for the script used in "sd-IN", the result is "Arab", not
   "Deva".

>

I had to create a replacement function for ResolveLocaleName which
doesn't return totally screwy and unexpected results, and special case
two more locales in /proc/locales output so the output makes sense.


Aha - a nice new 3.5.0 feature - as well as /proc/codesets - is that charsets 
e.g. ISO-10646, etc. rather than encodings e.g. UTF-8, etc.!


FYI Google fixed their English L14N falling back to en-GB except US territories:

https://developer.android.com/guide/topics/resources/multilingual-support#postN
https://issuetracker.google.com/issues/64429534#comment6

and there have been similar issues posted for other languages.


Oh, and I added error handling to the code so newlocale is now able to
set errno to ENOENT if the locale is not supported.

If you want to test this, the changes are in test release
3.5.0-0.260.gb5b67a65f87c, which is just building.

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: newlocale: Linux incompatibility

[Corinna Vinschen via Cygwin]

On Mar 24 09:57, Ken Brown via Cygwin wrote:
> On 3/24/2023 8:18 AM, Corinna Vinschen via Cygwin wrote:
> > On Mar 23 22:14, Corinna Vinschen via Cygwin wrote:
> > > On Mar 23 15:48, Ken Brown via Cygwin wrote:
> > > > Consider the following test case:
> > > > 
> > > > $ cat locale_test.c
> > > > #include 
> > > > #include 
> > > > 
> > > > int main ()
> > > > {
> > > >const char *locale = "en_DE.UTF-8";
> > > >locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK, locale, 
> > > > 0);
> > > >if (!loc)
> > > >  perror ("newlocale");
> > > >else
> > > >  printf ("newlocale succeeded on invalid locale %s\n", locale);
> > > > }
> > > > 
> > > > $ gcc -o locale_test locale_test.c
> > > > 
> > > > $ ./locale_test.exe
> > > > newlocale succeeded on invalid locale en_DE.UTF-8
> > > > 
> > > > On Linux, the newlocale call fails with ENOENT, as is documented on the 
> > > > man
> > > > page.
> > > Three bugs in fact.
> > > [...]
> > I pushed a couple of patches which hopefully clean up the code.
> > [...]
> > If you want to test this, the changes are in test release
> > 3.5.0-0.260.gb5b67a65f87c, which is just building.
> 
> That was fast!  I can confirm that newlocale now fails with ENOENT on the
> invalid locale en_XY.utf8.

Thanks for testing!


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: newlocale: Linux incompatibility

[Ken Brown via Cygwin]

On 3/24/2023 8:18 AM, Corinna Vinschen via Cygwin wrote:

On Mar 23 22:14, Corinna Vinschen via Cygwin wrote:

On Mar 23 15:48, Ken Brown via Cygwin wrote:

Consider the following test case:

$ cat locale_test.c
#include 
#include 

int main ()
{
   const char *locale = "en_DE.UTF-8";
   locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK, locale, 0);
   if (!loc)
 perror ("newlocale");
   else
 printf ("newlocale succeeded on invalid locale %s\n", locale);
}

$ gcc -o locale_test locale_test.c

$ ./locale_test.exe
newlocale succeeded on invalid locale en_DE.UTF-8

On Linux, the newlocale call fails with ENOENT, as is documented on the man
page.

Three bugs in fact.

First, it's a bug in the Emacs testsuite.  The test simply assumes that
there's no en_DE locale on any system, but that's just not true.
Windows support the RFC 5646 locale "en-DE", which is called "English
(Germany)" in the "Region" settings.

You can also check with `locale -av | less' and search for en_DE.

For the reminder of this mail, I assume you're talking about Cygwin 3.5.
I won't fix this for 3.4 anymore, given how much locale handling has
changed for 3.5.

The second bug is that Cygwin blindly trusts the Windows function
ResolveLocaleName().  That function blatantly converts even vaguely
similar locales into something it supports.  E.g., it converts "en-XY"
to "en-US".  I. .e., even if you use "en_XY.utf8" as locale, the above
testcase will wrongly succeed.  So I have to rethink how I resolve POSIX
locales to Windows locales.

And the third bug is that Cygwin fails to set errno if it doesn't
support a locale, but that's a minor inconvenience in comparison.

Thanks for the report, I totally missed the above problem with
ResolveLocaleName.


I pushed a couple of patches which hopefully clean up the code. 


I had to create a replacement function for ResolveLocaleName which
doesn't return totally screwy and unexpected results, and special case
two more locales in /proc/locales output so the output makes sense.

Oh, and I added error handling to the code so newlocale is now able to
set errno to ENOENT if the locale is not supported.

If you want to test this, the changes are in test release
3.5.0-0.260.gb5b67a65f87c, which is just building.


That was fast!  I can confirm that newlocale now fails with ENOENT on 
the invalid locale en_XY.utf8.


Thanks.

Ken

--
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: newlocale: Linux incompatibility

[Corinna Vinschen via Cygwin]

On Mar 23 22:14, Corinna Vinschen via Cygwin wrote:
> On Mar 23 15:48, Ken Brown via Cygwin wrote:
> > I'm reporting this here rather than the newlib list because the behavior is
> > compatible with Posix but not Linux, so I think it's a Cygwin issue.
> 
> Actually, it's a Windows issue :)
> 
> > Consider the following test case:
> > 
> > $ cat locale_test.c
> > #include 
> > #include 
> > 
> > int main ()
> > {
> >   const char *locale = "en_DE.UTF-8";
> >   locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK, locale, 0);
> >   if (!loc)
> > perror ("newlocale");
> >   else
> > printf ("newlocale succeeded on invalid locale %s\n", locale);
> > }
> > 
> > $ gcc -o locale_test locale_test.c
> > 
> > $ ./locale_test.exe
> > newlocale succeeded on invalid locale en_DE.UTF-8
> > 
> > On Linux, the newlocale call fails with ENOENT, as is documented on the man
> > page.  Posix doesn't say what should happen on an invalid locale, so this is
> > not, strictly speaking, a bug.
> 
> Three bugs in fact.
> 
> First, it's a bug in the Emacs testsuite.  The test simply assumes that
> there's no en_DE locale on any system, but that's just not true.
> Windows support the RFC 5646 locale "en-DE", which is called "English
> (Germany)" in the "Region" settings.
> 
> You can also check with `locale -av | less' and search for en_DE.
> 
> For the reminder of this mail, I assume you're talking about Cygwin 3.5.
> I won't fix this for 3.4 anymore, given how much locale handling has
> changed for 3.5.
> 
> The second bug is that Cygwin blindly trusts the Windows function
> ResolveLocaleName().  That function blatantly converts even vaguely
> similar locales into something it supports.  E.g., it converts "en-XY"
> to "en-US".  I. .e., even if you use "en_XY.utf8" as locale, the above
> testcase will wrongly succeed.  So I have to rethink how I resolve POSIX
> locales to Windows locales.
> 
> And the third bug is that Cygwin fails to set errno if it doesn't
> support a locale, but that's a minor inconvenience in comparison.
> 
> Thanks for the report, I totally missed the above problem with
> ResolveLocaleName.

I pushed a couple of patches which hopefully clean up the code.  It's
really frustrating how these Windows locale functions work.  Or, rather,
not work.  I mean, come on...

- ResolveLocaleName() resolves "ff-BF" to "ff-Latn-SN", not to
  "ff-Adlm-BF" or "ff-Latn-BF", even though both exist.  

- There's a locale called "sd-Arab-PK" and a locale "sd-Deva-IN".  If
  you ask for the script used in "sd-IN", the result is "Arab", not
  "Deva".

/*facepalm*/

I had to create a replacement function for ResolveLocaleName which
doesn't return totally screwy and unexpected results, and special case
two more locales in /proc/locales output so the output makes sense.

Oh, and I added error handling to the code so newlocale is now able to
set errno to ENOENT if the locale is not supported.

If you want to test this, the changes are in test release
3.5.0-0.260.gb5b67a65f87c, which is just building.


HTH,
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: newlocale: Linux incompatibility

[Corinna Vinschen via Cygwin]

On Mar 23 15:48, Ken Brown via Cygwin wrote:
> I'm reporting this here rather than the newlib list because the behavior is
> compatible with Posix but not Linux, so I think it's a Cygwin issue.

Actually, it's a Windows issue :)

> Consider the following test case:
> 
> $ cat locale_test.c
> #include 
> #include 
> 
> int main ()
> {
>   const char *locale = "en_DE.UTF-8";
>   locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK, locale, 0);
>   if (!loc)
> perror ("newlocale");
>   else
> printf ("newlocale succeeded on invalid locale %s\n", locale);
> }
> 
> $ gcc -o locale_test locale_test.c
> 
> $ ./locale_test.exe
> newlocale succeeded on invalid locale en_DE.UTF-8
> 
> On Linux, the newlocale call fails with ENOENT, as is documented on the man
> page.  Posix doesn't say what should happen on an invalid locale, so this is
> not, strictly speaking, a bug.

Three bugs in fact.

First, it's a bug in the Emacs testsuite.  The test simply assumes that
there's no en_DE locale on any system, but that's just not true.
Windows support the RFC 5646 locale "en-DE", which is called "English
(Germany)" in the "Region" settings.

You can also check with `locale -av | less' and search for en_DE.

For the reminder of this mail, I assume you're talking about Cygwin 3.5.
I won't fix this for 3.4 anymore, given how much locale handling has
changed for 3.5.

The second bug is that Cygwin blindly trusts the Windows function
ResolveLocaleName().  That function blatantly converts even vaguely
similar locales into something it supports.  E.g., it converts "en-XY"
to "en-US".  I. .e., even if you use "en_XY.utf8" as locale, the above
testcase will wrongly succeed.  So I have to rethink how I resolve POSIX
locales to Windows locales.

And the third bug is that Cygwin fails to set errno if it doesn't
support a locale, but that's a minor inconvenience in comparison.

Thanks for the report, I totally missed the above problem with
ResolveLocaleName.


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: newlocale: Linux incompatibility

[Thomas Wolff via Cygwin]

Am 23.03.2023 um 20:48 schrieb Ken Brown via Cygwin:
I'm reporting this here rather than the newlib list because the 
behavior is compatible with Posix but not Linux, so I think it's a 
Cygwin issue.


Consider the following test case:

$ cat locale_test.c
#include 
#include 

int main ()
{
  const char *locale = "en_DE.UTF-8";
  locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK, locale, 0);
  if (!loc)
    perror ("newlocale");
  else
    printf ("newlocale succeeded on invalid locale %s\n", locale);
}

$ gcc -o locale_test locale_test.c

$ ./locale_test.exe
newlocale succeeded on invalid locale en_DE.UTF-8

On Linux, the newlocale call fails with ENOENT, as is documented on 
the man page.  Posix doesn't say what should happen on an invalid 
locale, so this is not, strictly speaking, a bug.
So the question is what is an invalid locale. In Linux, locales are only 
valid if explicitly listed somewhere.
This strict behaviour may be a problem. A much better approach is to 
allow any combination of known language_REGIOIN tags with encoding 
indications, to be much more flexible and dynamic.
So if such combinations are considered legal, as in cygwin, this is not 
a bug.




Ken

P.S. I noticed this because of a failing Emacs test.  No one else has 
reported this test failure, so it seems that newlocale fails on an 
invalid locale on all platforms supported by Emacs other than 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

newlocale: Linux incompatibility

[Ken Brown via Cygwin]

I'm reporting this here rather than the newlib list because the behavior 
is compatible with Posix but not Linux, so I think it's a Cygwin issue.


Consider the following test case:

$ cat locale_test.c
#include 
#include 

int main ()
{
  const char *locale = "en_DE.UTF-8";
  locale_t loc = newlocale (LC_COLLATE_MASK | LC_CTYPE_MASK, locale, 0);
  if (!loc)
perror ("newlocale");
  else
printf ("newlocale succeeded on invalid locale %s\n", locale);
}

$ gcc -o locale_test locale_test.c

$ ./locale_test.exe
newlocale succeeded on invalid locale en_DE.UTF-8

On Linux, the newlocale call fails with ENOENT, as is documented on the 
man page.  Posix doesn't say what should happen on an invalid locale, so 
this is not, strictly speaking, a bug.


Ken

P.S. I noticed this because of a failing Emacs test.  No one else has 
reported this test failure, so it seems that newlocale fails on an 
invalid locale on all platforms supported by Emacs other than 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: General scripting issues vs. Linux

[Backwoods BC via Cygwin]

On Fri, Mar 10, 2023 at 8:16 AM Brian Inglis via Cygwin
 wrote:
>
> On 2023-03-10 06:59, Ken Brown via Cygwin wrote:
> > On 3/10/2023 8:47 AM, Markus Becker via Cygwin wrote:
> >> I am quite an newby in Cygwin scripting and encountered several execution
> >> issues with bash scripts. For example, when i try to execute the following
> >> simple scriptfile "skript1.sh":
> >> # This is a testscript
> >> Statement="This is the testscript number 3"
> >> FILE="home/mbecker/Secure_Copy_Beispiel.txt"
> >> ls -l $FILE
> >> echo $Statement
> >> echo The file is $FILE
> >> i got these results:
> >> $ ./skript1.sh
> >> ls: cannot access 'home/mbecker/Secure_Copy_Beispiel.txt'$'\r\r': No such
>   ^
> >> file or directory
> >> This is the testscript number 3
> >> The file is home/mbecker/Secure_Copy_Beispiel.txt
> >> or another results from a different script:
> >> $ ./skript7.sh
> >> ./skript7.sh: line 3: $'clear\r': command not found
>  ^^^
> >> Dr▒cken sie beliebige Tasten und dann return
> >> ': not a valid identifierd: `TASTE
> >> These are just two of several issues coming up with bash scripting in
> >> Cygwin. Maybe this is merely a corse problem with my platform
> >> understanding. But why is Cygwin calling errors when performing standard
> >> Linux bash commands? Is it due to a different syntax? Or is it even 
> >> simpler?
>
> > It looks like your scripts have CRLF line endings.
>
> Utilities such as coreutils, gawk, grep, sed, etc. Cygwin packages had Cygwin
> tweaks removed in 2017 to be compatible with Linux and other platforms in
> handling '\r' before newlines, except for the single exception of Cygwin text
> mounts, where '\r' may be stripped if a program opens a file from that mount 
> in
> text "t" mode, and may be added on writes to a file in text "t" mode on a text
> mount:
>
> https://www.cygwin.com/cygwin-ug-net/using-textbinary.html
>
> discussions:
>
> https://cygwin.com/legacy-ml/cygwin/2017-02/msg00152.html
> https://cygwin.com/legacy-ml/cygwin/2017-02/msg00188.html
> https://cygwin.com/legacy-ml/cygwin/2017-02/msg00189.html
>
> Install package dos2unix which conveniently strips the offending junk from 
> your
> scripts and files e.g.
>
> d2u -k skript*.sh
>
> Install and use Cygwin editors and utilities, or check editor and utility
> settings to ensure they are not set to behave like Windows e.g. gvim set
> fileformat=unix termencoding=utf-8 fileencoding=utf-8 in your ~/.gvimrc 
> ~/.vimrc
> ~/.virc ~/.exrc; emacs (set-buffer-file-coding-system 'mule-utf-8-unix) in
> ~/.emacs, type C-x C-q C-m f mule-utf-8-unix, or do the equivalent in more
> sophisticated initializations (auto)detecting file type, encoding, and format;
> for git config --global core.autocrlf = input, see:
>
> https://stackoverflow.com/questions/3206843/how-line-ending-conversions-work-with-git-core-autocrlf-between-different-operat
>
> --
> Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

As a matter of expediency, I always pass files through '| tr -d '\r'
|' when reading them. This is harmless on Linux and you don't have to
worry whether or not your target system has 'd2u' installed since I
believe that 'tr' is part of all base installations. It also means you
don't have to worry about whether or not a particular program handles
'\r' automagically.

I find that it is also a good idea to save all script files as UTF-8
so that they can handle Windows filenames with emojis and such in them
when explicitly named in the script.

-- 
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: General scripting issues vs. Linux

[Brian Inglis via Cygwin]

On 2023-03-10 06:59, Ken Brown via Cygwin wrote:

On 3/10/2023 8:47 AM, Markus Becker via Cygwin wrote:

I am quite an newby in Cygwin scripting and encountered several execution
issues with bash scripts. For example, when i try to execute the following
simple scriptfile "skript1.sh":
# This is a testscript
Statement="This is the testscript number 3"
FILE="home/mbecker/Secure_Copy_Beispiel.txt"
ls -l $FILE
echo $Statement
echo The file is $FILE
i got these results:
$ ./skript1.sh
ls: cannot access 'home/mbecker/Secure_Copy_Beispiel.txt'$'\r\r': No such

 ^

file or directory
This is the testscript number 3
The file is home/mbecker/Secure_Copy_Beispiel.txt
or another results from a different script:
$ ./skript7.sh
./skript7.sh: line 3: $'clear\r': command not found

^^^

Dr▒cken sie beliebige Tasten und dann return
': not a valid identifierd: `TASTE
These are just two of several issues coming up with bash scripting in
Cygwin. Maybe this is merely a corse problem with my platform
understanding. But why is Cygwin calling errors when performing standard
Linux bash commands? Is it due to a different syntax? Or is it even simpler?



It looks like your scripts have CRLF line endings.


Utilities such as coreutils, gawk, grep, sed, etc. Cygwin packages had Cygwin 
tweaks removed in 2017 to be compatible with Linux and other platforms in 
handling '\r' before newlines, except for the single exception of Cygwin text 
mounts, where '\r' may be stripped if a program opens a file from that mount in 
text "t" mode, and may be added on writes to a file in text "t" mode on a text 
mount:


https://www.cygwin.com/cygwin-ug-net/using-textbinary.html

discussions:

https://cygwin.com/legacy-ml/cygwin/2017-02/msg00152.html
https://cygwin.com/legacy-ml/cygwin/2017-02/msg00188.html
https://cygwin.com/legacy-ml/cygwin/2017-02/msg00189.html

Install package dos2unix which conveniently strips the offending junk from your 
scripts and files e.g.


d2u -k skript*.sh

Install and use Cygwin editors and utilities, or check editor and utility 
settings to ensure they are not set to behave like Windows e.g. gvim set 
fileformat=unix termencoding=utf-8 fileencoding=utf-8 in your ~/.gvimrc ~/.vimrc 
~/.virc ~/.exrc; emacs (set-buffer-file-coding-system 'mule-utf-8-unix) in 
~/.emacs, type C-x C-q C-m f mule-utf-8-unix, or do the equivalent in more 
sophisticated initializations (auto)detecting file type, encoding, and format; 
for git config --global core.autocrlf = input, see:


https://stackoverflow.com/questions/3206843/how-line-ending-conversions-work-with-git-core-autocrlf-between-different-operat

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

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry

--
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: General scripting issues vs. Linux

[Ken Brown via Cygwin]

On 3/10/2023 8:47 AM, Markus Becker via Cygwin wrote:

Dear Guys,

I am quite an newby in Cygwin scripting and encountered several execution
issues with bash scripts. For example, when i try to execute the following
simple scriptfile "skript1.sh":

# This is a testscript
Statement="This is the testscript number 3"
FILE="home/mbecker/Secure_Copy_Beispiel.txt"
ls -l $FILE
echo $Statement
echo The file is $FILE

i got these results:

$ ./skript1.sh
ls: cannot access 'home/mbecker/Secure_Copy_Beispiel.txt'$'\r\r': No such
file or directory
This is the testscript number 3
The file is home/mbecker/Secure_Copy_Beispiel.txt

or another results from a different script:

$ ./skript7.sh
./skript7.sh: line 3: $'clear\r': command not found
Dr▒cken sie beliebige Tasten und dann return
': not a valid identifierd: `TASTE

These are just two of several issues coming up with bash scripting in
Cygwin. Maybe this is merely a corse problem with my platform
understanding. But why is Cygwin calling errors when performing standard
Linux bash commands? Is it due to a different syntax? Or is it even simpler?


It looks like your scripts have CRLF line endings.

Ken

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

General scripting issues vs. Linux

[Markus Becker via Cygwin]

Dear Guys,

I am quite an newby in Cygwin scripting and encountered several execution
issues with bash scripts. For example, when i try to execute the following
simple scriptfile "skript1.sh":

# This is a testscript
Statement="This is the testscript number 3"
FILE="home/mbecker/Secure_Copy_Beispiel.txt"
ls -l $FILE
echo $Statement
echo The file is $FILE

i got these results:

$ ./skript1.sh
ls: cannot access 'home/mbecker/Secure_Copy_Beispiel.txt'$'\r\r': No such
file or directory
This is the testscript number 3
The file is home/mbecker/Secure_Copy_Beispiel.txt

or another results from a different script:

$ ./skript7.sh
./skript7.sh: line 3: $'clear\r': command not found
Dr▒cken sie beliebige Tasten und dann return
': not a valid identifierd: `TASTE

These are just two of several issues coming up with bash scripting in
Cygwin. Maybe this is merely a corse problem with my platform
understanding. But why is Cygwin calling errors when performing standard
Linux bash commands? Is it due to a different syntax? Or is it even simpler?

I would appreciate any advice and information on this. As i said, i am
quite used to Cygwin, but not so to scripting in Cygwin.

Thanks a lot
Markus

-- 
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: man-pages-linux 6.03

[Cygwin Linux Man Pages Maintainer via Cygwin-announce via Cygwin]

The following package has been upgraded in the Cygwin distribution:

* man-pages-linux   6.03

Documents the Linux kernel system calls and C library interfaces used
by programs, plus system and administrative utilities, devices, file
system, file, and data formats, and related information.

For more information, see the project home page:

https://kernel.org/doc/man-pages/

You may also search and read the pages online:

https://man7.org/linux/man-pages/

although the latest release may not yet be available. 
A new updated site may be announced in a future release.

NOTE:
The previous releases named the directory linux, but this was searched
before Cygwin man pages, leading to unexpected results in most cases.
>From this release the directory used is man-pages-linux, and linux is
provided as a convenience backward compatibility symlink. 
If you prefer to see Linux man pages over Cygwin man pages, then use
-m|--systems linux in the examples below, or add -m linux to a command.

As Cygwin has its own man pages with some conflicts, these man pages are
installed under /usr/share/man/man-pages-linux/, so by default searching
or viewing these pages requires the option:

$ apropos -m|--systems man-pages-linux ...
$ man -m|--systems man-pages-linux ...

Cygwin man pages are under the default system "man", so for convenience
both systems may be specified separated by comma e.g.

$ man -m man,man-pages-linux ...

The path or option may also be added explicitly to a users MANPATH or
alias e.g.

$ export MANPATH=$MANPATH:/usr/share/man/man-pages-linux

$ alias apropos='apropos -m man,man-pages-linux'
$ alias man='man -m man,man-pages-linux'

Add -a to show both Cygwin and Linux (and POSIX if companion package
man-pages-posix is also installed) manual pages.

Release 6 added some section 2 and 3 pages suffixed by const, head,
or type installed in the base section directories.

For recent changes, please see below, or after installation read
/usr/share/doc/man-pages-linux/Changes:


man-pages-6.03  2023-02-12

Global changes

* Build system:
  - Add scripts to produce a book of the Linux man-pages.
  - Add lint-c-cppcheck to the make(1) targets to run the cppcheck(1)
linter.

* TH:
  - Use correct letter case in page titles. This started in 6.02, but
there were still many cases left.

* SYNOPSIS:
  - Mark some functions as deprecated.

* STANDARDS:
  - Remove most references to ISO C89.  We still document it in
standards(7), but it's an ancient language version that this project
regards as obsolescent, so in the STANDARDS sections for APIs we
only take into account C99 and later and POSIX.1-2001 and later
(with few exceptions where older standards are relevant).

* ffix:
  - Change \- to - where appropriate
  - Improve readability of numbers:
- Show BCD magic numbers that are meaningful in hex as hex,
   rather than weird decimal numbers.
- Use IEC multipliers.
  - Format ranges consistently using interval notation: [min, max].

* srcfix:
  - Use \[] escapes.

Changes to individual pages

* timespec.3type
Update tv_nsec according to C2x.

The manual pages (and other files in the repository) have been improved
beyond what this changelog covers.  To learn more about changes applied
to individual pages, use git(1).

New and rewritten pages

* man3/
arc4random.3
powerof2.3
roundup.3

* man3head/
printf.h.3head

Newly documented interfaces in existing pages

* perf_event_open.2
PERF_COUNT_SW_BPF_OUTPUT
PERF_COUNT_SW_CGROUP_SWITCHES
PERF_FORMAT_LOST
PERF_RECORD_MISC_MMAP_BUILD_ID
PERF_RECORD_MISC_SWITCH_OUT_PREEMPT
PERF_SAMPLE_CODE_PAGE_SIZE
PERF_SAMPLE_DATA_PAGE_SIZE
PERF_SAMPLE_WEIGHT_STRUCT

struct perf_event_attr::build_id
struct perf_event_attr::inherit_thread
struct perf_event_attr::remove_on_exec
struct perf_event_attr::sigtrap
struct perf_event_attr::aux_sample_size
struct perf_event_attr::sig_data

union perf_sample_weight

struct read_format::values[]::lost

struct::weight
struct::data_page_size
struct::code_page_size
struct::size
struct::data

struct:: ::build_id_size
struct:: ::build_id

* prctl.2
PR_SET_VMA
PR_SET_VMA_ANON_NAME

New and changed links

* man3/
arc4random_buf.3(arc4random(3))
arc4random_uniform.3(arc4random(3))
register_printf_modifier.3  (printf.h(3head))
register_printf_specifier.3 (printf.h(3head))
register_printf_type.3  (printf.h(3head))

* man3const/
PA_CHAR.3const  (printf.h(3head))
PA_DOUBLE.3const(printf

[ANNOUNCEMENT] Updated: man-pages-linux 6.02

[Cygwin Linux Man Pages Maintainer via Cygwin-announce via Cygwin]

The following package has been upgraded in the Cygwin distribution:

* man-pages-linux   6.02

Documents the Linux kernel system calls and C library interfaces used
by programs, plus system and administrative utilities, devices, file
system, file, and data formats, and related information.

For more information, see the project home page:

https://kernel.org/doc/man-pages/

You may also search and read the pages online:

https://man7.org/linux/man-pages/

although the latest release may not yet be available. 

As Cygwin has its own man pages with some conflicts, these man pages
are installed under /usr/share/man/linux/, so by default searching
or viewing these pages requires the option:

$ apropos -m|--systems linux ...
$ man -m|--systems linux ...

Cygwin man pages are under the default system "man", so for convenience
both systems may be specified separated by comma e.g.

$ man -m man,linux ...

The path or option may also be added explicitly to a users MANPATH or
alias e.g.

$ export MANPATH=$MANPATH:/usr/share/man/linux

$ alias apropos='apropos -m man,linux'
$ alias man='man -m man,linux'

Add -a to show both Cygwin and Linux manual pages if present, or swap
the order to prioritize Linux.

Release 6 added some section 2 and 3 pages suffixed by const, head,
or type installed in the base section directory.

For recent changes, please see below, or after installation read
/usr/share/doc/man-pages-linux/Changes:


man-pages-6.02  2022-12-22

Global changes

* Use correct letter case in manual page titles, instead of uppercase.
* Use \" t comments when appropriate (Lintian needs this).
* SYNOPSIS:
  - Add _Nullable for functions that receive NULL as a meaningful input.
  - Use VLA syntax to clarify the meaning of size parameters, rather
than hiding it in possibly-confusing text. This syntax is not
accepted by any compilers, though.
  - Use [[noreturn]] instead of noreturn, which will be deprecated soon.
* Repository documentation:
  - Added significant documentation about the repository and the project
in the root of the repository in different files.  Starting from the
README, anyone passing by should be able to understand how the
project works and be directed to other documentation files. These
files also document the release process.
  - Michael has been busy lately, and he is no longer maintaining the
project. The in-repository documentation mentioned above has been
updated to reflect that.

Changes to individual pages

* copy_file_range.2
Fix wrong kernel version information
* process_madvise.2
Fix capability and ptrace requirements
* madvise.2
Update Transparent Huge Pages file/shmem documentation for Linux 5.4+.

New and rewritten pages

* man3/
static_assert.3
strcpy.3
stpncpy.3
strncat.3
* man3const/
EOF.3const
EXIT_SUCCESS.3const
* man7/
string_copying.7

New and changed links

* man3/
_Static_assert.3(static_assert(3))
stpcpy.3(strcpy(3))
strcat.3(strcpy(3))
strncpy.3   (stpncpy(3))
stpecpy.3   (string_copying(7))
stpecpyx.3  (string_copying(7))
ustpcpy.3   (string_copying(7))
ustr2stp.3  (string_copying(7))
zustr2stp.3 (string_copying(7))
zustr2ustp.3(string_copying(7))
* man3const/
EXIT_FAILURE.3const (EXIT_SUCCESS(3const))

Newly documented interfaces in existing pages

* ioctl_tty.2
TIOCSERGETLSR
TIOCSER_TEMT
* madvise.2
MADV_COLLAPSE
* syscall.2
loongarch

The manual pages (and other files in the repository) have been improved
beyond what this changelog covers. To learn more about changes applied
to individual pages, use git(1).


-- 
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: man-pages-linux 6.01

[Cygwin Linux Man Pages Maintainer]

The following package has been upgraded in the Cygwin distribution:

* man-pages-linux   6.01

Documents the Linux kernel system calls and C library interfaces used
by programs, plus system and administrative utilities, devices, file
system, file, and data formats, and related information.

For more information, see the project home page:

https://kernel.org/doc/man-pages/

You may also search and read the pages online:

https://man7.org/linux/man-pages/

although the latest release may not yet be available. 

Release 6 added some section 2 and 3 pages suffixed by const, head,
or type installed in the base section directory.

As Cygwin has its own man pages with some conflicts, these man pages
are installed under /usr/share/man/linux/, so by default searching
or viewing these pages requires the option:

$ apropos -m|--systems linux ...
$ man -m|--systems linux ...

Cygwin man pages are under the default system "man", so for convenience
both systems may be specified separated by comma e.g.

$ man -m man,linux ...

The path or option may also be added explicitly to a users MANPATH or
alias e.g.

$ export MANPATH=$MANPATH:/usr/share/man/linux

$ alias apropos='apropos -m man,linux'
$ alias man='man -m man,linux'

Add -a to show both Cygwin and Linux manual pages if present, or swap
the order to prioritize Linux.

For recent changes, please see below, or after installation read
/usr/share/doc/man-pages-linux/CHANGES:


man-pages-6.01  2022-10-18

Global changes

* Manual pages' sections:

- Title (.TH):

  - Remove the hardcoded date (TH 3rd argument), and replace it by a
placeholder that should be changed when creating the tarball.
This removes the need for a tstamp commit before each release.

* Build system:

- Update manual page dates (TH 3rd argument) when creating the tarball
  with 'make dist'.  this removes the need for a tstamp commit before
  each release.

- Don't print spurious errors from the Makefile that are not relevant.

Changes to individual pages

The manual pages (and other files in the repository) have been improved
beyond what this changelog covers.

New and rewritten pages

* EOF.3const

Newly documented interfaces in existing pages

* fanotify_mark.2
FAN_MARK_IGNORE

* open.2, statx.2
STATX_DIOALIGN

* feature_test_macros.7
_FORTIFY_SOURCE=3
_TIME_BITS


-- 
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: man-pages-linux 6.00

[Cygwin Linux Man Pages Maintainer]

The following package has been upgraded in the Cygwin distribution:

* man-pages-linux   6.00

Documents the Linux kernel system calls and C library interfaces used
by programs, plus system and administrative utilities, devices, file
system, file, and data formats, and related information.

For more information, see the project home page:

https://kernel.org/doc/man-pages/

You may also search and read the pages online:

https://man7.org/linux/man-pages/

although the latest release may not yet be available. 

This major release adds some section 2 and 3 pages suffixed by
const, head, or type installed in the base section directory.

As Cygwin has its own man pages with some conflicts, these man pages
are installed under /usr/share/man/linux/, so by default searching
or viewing these pages requires the option:

$ apropos -m|--systems linux ...
$ man -m|--systems linux ...

Cygwin man pages are under the default system "man", so for convenience
both systems may be specified separated by comma e.g.

$ man -m man,linux ...

The path or option may also be added explicitly to a users MANPATH or
alias e.g.

$ export MANPATH=$MANPATH:/usr/share/man/linux

$ alias apropos='apropos -m man,linux'
$ alias man='man -m man,linux'

Add -a to show both Cygwin and Linux manual pages if present, or swap
the order to prioritize Linux.

For recent changes, please see below, or after installation read
/usr/share/doc/man-pages-linux/CHANGES:


Version 6.002022-10-09

Global changes

* Man dirs:

  - Move definitions of types to separate pages in man2type/ and
man3type/. Previously, they were spread (and duplicated) in other
pages, or in system_data_types.7 (with links in man3/).

  - Add man3head/ for pages that document header files.

  - Add man3const/ for pages that document constants.

* Licenses:

  - Use SPDX-License-Identifier for licenses specified by SPDX
    (including the newly-added Linux-man-pages-copyleft). This reduces
the overhead text at the top of most manual page source files.
License texts have been moved to LICENSES/.

* Build system:

  - Add several make(1) targets to lint the manual pages, and also lint
and build the C programs contained in them. Use of these targets
requires unreleased versions of software, such as groff-1.23.0, so
it's not yet intended to be used by the public.

  - Add targets to build tarballs of the repository.

* man(7) source:

  - Improve consistency of man(7) source. Also, reduce the number of
warnings that groff(1) and mandoc(7) emit when parsing the pages
with the highest warning level. Most of these fixes were found
thanks to the new `make lint-man` target.

* Manual pages sections:

  - Title (.TH):

- Remove 5th argument to TH (middle-header).

- Specify "Linux man-pages" and the version in the 4th argument
  (left-footer).

  - Add the LIBRARY section.  This section standardizes a way to
document the library that provides a given interface.

  - Add the CAVEATS section.  BUGS and NOTES were serving that purpose
before, but CAVEATS is more appropriate.

  - Rename the CONFORMING TO section to STANDARDS for consistency with
other projects, such as the BSDs.

  - SYNOPSIS:  Add the ISO C2X [[deprecated]] attribute for functions
that have been deprecated or removed.

  - EXAMPLES:  Improve consistency of C source code.  Also, reduce the
number of warnings that several linting tools emit.

  - COLOPHON:  Remove section (its purpose is now served by the title).

* Repository:

  - CONTRIBUTING, README, INSTALL:  Document important changes in the
project organization.

Changes to individual pages

The manual pages (and other files in the repository) have been improved
beyond what this changelog covers.

New and rewritten pages

* man2/
  landlock_add_rule.2
  landlock_create_ruleset.2
  landlock_restrict_self.2
  memfd_secret.2

* man2type/
  open_how.2type

* man3/
  _Generic.3

* man3const/
  NULL.3const

* man3head/
  sysexits.h.3head

* man3type/
  aiocb.3type
  blkcnt_t.3type
  blksize_t.3type
  cc_t.3type
  clock_t.3type
  clockid_t.3type
  dev_t.3type
  div_t.3type
  double_t.3type
  epoll_event.3type
  fenv_t.3type
  id_t.3type
  intN_t.3type
  intmax_t.3type
  intptr_t.3type
  iovec.3type
  itimerspec.3type
  lconv.3type
  mode_t.3type
  off_t.3type
  ptrdiff_t.3type
  regex_t.3type
  size_t.3type
  sockaddr.3type
  stat.3type
  time_t.3type
  timer_t.3type
  timespec.3type
  timeval.3type
  tm.3type
  va_list.3type
  void.3type

* man7/
  landlock.7

Newly documented interfaces in existing pages

* epoll_wait.2
  epoll_pwait2(2)

* fanotify_init.2
  FAN_REPORT_PIDFD

* fanotify_mark.2
  FAN_FS_ERROR
  FAN_MARK_EVICTABLE
  FAN_RENAME
  FAN_REPORT_TARGET_FID

* madvise.2
  MADV_POPULATE_READ
  MADV_POPULATE_WRITE

* pipe.2
  O_NOTIFICATION_PIPE

* process_madvise.2
  MADV_WILLN

Re: SSH connection from Linux to Windows by CYGSSHD: port 22

[Andrey Repin]

Greetings, Chris Roehrig!

> I recently had to add the following lines to my Cygwin /etc/sshd_config to
> re-enable RSA in order for my older machines to connect:

> HostKeyAlgorithms +ssh-rsa
> PubkeyAcceptedAlgorithms +ssh-rsa

I'm not using RSA for, like, 5 years now.
Too long to manage.

> -- Chris

> On 2022-03-31 06:18, Andrey Repin wrote:
>> Greetings, Greco Giovanni!
>>
>>> must port 22 on Windows server be enabled in a bidirectional way to
>>> establish a connection with RSA key exchange?
>>> I have a Linux server on a vlan and a Windows server on another vlan, those
>>> vlans are connected thru a firewall, where port 22 is enabled from Linux
>>> server to Windows server unidirectionally.
>>> Connection with user and password works, but not with RSA key exchange: is
>>> the problem located on port 22 unidirectional enabling?
>> No, it is most likely because you are connecting to Microsoft provided
>> OpenSSH.
>> `netstat -aon` and `ps ax` will tell you more.
>>
>>




-- 
With best regards,
Andrey Repin
Thursday, March 31, 2022 23:03:27

Sorry for my terrible english...


-- 
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: SSH connection from Linux to Windows by CYGSSHD: port 22

[Chris Roehrig]

I recently had to add the following lines to my Cygwin /etc/sshd_config 
to re-enable RSA in order for my older machines to connect:


HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa


-- Chris

On 2022-03-31 06:18, Andrey Repin wrote:

Greetings, Greco Giovanni!


must port 22 on Windows server be enabled in a bidirectional way to
establish a connection with RSA key exchange?
I have a Linux server on a vlan and a Windows server on another vlan, those
vlans are connected thru a firewall, where port 22 is enabled from Linux
server to Windows server unidirectionally.
Connection with user and password works, but not with RSA key exchange: is
the problem located on port 22 unidirectional enabling?

No, it is most likely because you are connecting to Microsoft provided
OpenSSH.
`netstat -aon` and `ps ax` will tell you more.





--
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: SSH connection from Linux to Windows by CYGSSHD: port 22

[Andrey Repin]

Greetings, Greco Giovanni!

> must port 22 on Windows server be enabled in a bidirectional way to
> establish a connection with RSA key exchange?
> I have a Linux server on a vlan and a Windows server on another vlan, those
> vlans are connected thru a firewall, where port 22 is enabled from Linux
> server to Windows server unidirectionally.
> Connection with user and password works, but not with RSA key exchange: is
> the problem located on port 22 unidirectional enabling?

No, it is most likely because you are connecting to Microsoft provided
OpenSSH.
`netstat -aon` and `ps ax` will tell you more.


-- 
With best regards,
Andrey Repin
Thursday, March 31, 2022 16:16:07

Sorry for my terrible english...


-- 
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 connection from Linux to Windows by CYGSSHD: port 22

[Greco Giovanni]

Hello,
must port 22 on Windows server be enabled in a bidirectional way to establish a 
connection with RSA key exchange?
I have a Linux server on a vlan and a Windows server on another vlan, those 
vlans are connected thru a firewall, where port 22 is enabled from Linux server 
to Windows server unidirectionally.
Connection with user and password works, but not with RSA key exchange: is the 
problem located on port 22 unidirectional enabling?
Thanks in advance.
Giovanni Greco - BlueIT S.p.A.

-- 
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: Generating Linux Compatible binaries

[Eliot Moss]

On 12/3/2021 3:56 PM, Achim Gratz wrote:

Goswami-EXT, Himanshu writes:

I want to generate the Linux compatible binaries on Windows System.


If you are on a recent Windows version your easiest option is probably
to use WSL and use native compilation on Linux.  second easiest is
likely to set up a VM to run Linux in (that might actually be easier
than WSL if you already have some virtualisation environment set up for
something else, but you said you were on Windows).


Cygwin is a cross compiler which offers POSIX environment.


No, Cygwin is a user-space layer on top of Windows that provides a POSIX
environment for applications that target Cygwin (i.e. Cygwin
applications are neither Windows nor Linux applications).


But I could not find any Unix libraries to generate the Linux compatible 
binaries.
Could you please advice any steps that I can follow?


Just like you'd do on any other non-Linux system: set up a
cross-compilation toolchain and start compiling all dependencies until
you can finally compile whatever Linux application you wanted orginally.


Following up my previous post and the two others I have seen ...

Cross-compilation is a definite possibility.  However, you can't test
the result directly under Windows or Cygwin.  If you want to test, then
AFAIK a VM (or maybe qemu?) is your only option.

Best wishes - 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: Generating Linux Compatible binaries

[Achim Gratz]

Goswami-EXT, Himanshu writes:
> I want to generate the Linux compatible binaries on Windows System.

If you are on a recent Windows version your easiest option is probably
to use WSL and use native compilation on Linux.  second easiest is
likely to set up a VM to run Linux in (that might actually be easier
than WSL if you already have some virtualisation environment set up for
something else, but you said you were on Windows).

> Cygwin is a cross compiler which offers POSIX environment.

No, Cygwin is a user-space layer on top of Windows that provides a POSIX
environment for applications that target Cygwin (i.e. Cygwin
applications are neither Windows nor Linux applications).

> But I could not find any Unix libraries to generate the Linux compatible 
> binaries.
> Could you please advice any steps that I can follow?

Just like you'd do on any other non-Linux system: set up a
cross-compilation toolchain and start compiling all dependencies until
you can finally compile whatever Linux application you wanted orginally.


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

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

-- 
Problem reports:  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: Generating Linux Compatible binaries

[Michael Enright]

On Fri, Dec 3, 2021 at 8:51 AM Goswami-EXT, Himanshu
 wrote:
>
> Hi,
>
> I want to generate the Linux compatible binaries on Windows System.
> Cygwin is a cross compiler which offers POSIX environment.
> But I could not find any Unix libraries to generate the Linux compatible 
> binaries.
> Could you please advice any steps that I can follow?
>

Eliot Moss recommends a VM and that's a good option.

Another option is to use Cygwin to host a cross compiler. I  have used
Cygwin to build and install cross compilers that ran on Cygwin and
built code for my Raspberry Pi 2. There are many tutorials on building
and creating cross compilers and I won't try to equal them. But this
is a versatile method. If the target Linux was one that runs on a
different processor and a virtual machine would be inefficient or lack
the resources to carry out the build, then running a cross compiler on
your Windows machine, under Cygwin or otherwise, might be an option to
consider.

-- 
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: Generating Linux Compatible binaries

[Eliot Moss]

On 12/3/2021 11:50 AM, Goswami-EXT, Himanshu wrote:
> Hi,
>
> I want to generate the Linux compatible binaries on Windows System.
> Cygwin is a cross compiler which offers POSIX environment.
> But I could not find any Unix libraries to generate the Linux compatible 
binaries.
> Could you please advice any steps that I can follow?
>
> Thanks in Advance.
> Himanshu

Cygwin doesn't work that way.  It uses a custom built library that translates
POSIX system calls to similar Windows systems calls.  There are a few places,
such as file permissions, where differences will peek through.  Anyway, since
it does not run Linux compatiable libraries, it is not designed to build them.

The only solution I can recommend is to use a virtual machine, such as the 
Windows
Subsystem for Linux (WSL), Oracle Virtual Box, or VMWare.

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

Generating Linux Compatible binaries

[Goswami-EXT, Himanshu]

Hi,

I want to generate the Linux compatible binaries on Windows System.
Cygwin is a cross compiler which offers POSIX environment.
But I could not find any Unix libraries to generate the Linux compatible 
binaries.
Could you please advice any steps that I can follow?

Thanks in Advance.
Himanshu

-- 
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] New: man-pages-linux 5.13 - Linux Manual Pages

[Cygwin Linux Man Pages Package Maintainer]

The following new package has been added to the Cygwin distribution:

* man-pages-linux   5.13

Documents the Linux kernel system calls and C library interfaces used
by programs, plus system and administrative utilities, devices, file
system, file, and data formats, and related information.

For more information, please see the project home page:

https://kernel.org/doc/man-pages/

You may also search and read the pages online:

https://man7.org/linux/man-pages/

As Cygwin has its own man pages with some conflicts, these man pages are
installed under /usr/share/man/linux/, so by default searching or
viewing these pages requires the option:

$ apropos -m|--systems linux ...
$ man -m|--systems linux ...

Cygwin man pages are under the default system "man", so for convenience
both systems may be specified separated by comma e.g.

$ man -m man,linux ...

The path or option may also be added explicitly to a users MANPATH or
alias e.g.

$ export MANPATH=$MANPATH:/usr/share/man/linux

$ alias apropos='apropos -m man,linux'
$ alias man='man -m man,linux'

Add -a to show both Cygwin and Linux manual pages if present, or swap
the order to prioritize Linux.

For recent changes, please see below, or after installation read
/usr/share/doc/man-pages-linux/CHANGES:

https://man7.org/linux/man-pages/changelog.html


Version 5.13 2021-08-27

New and rewritten pages

* mount_setattr.2   New manual page for the mount_setattr() system call


Newly documented interfaces in existing pages

* futex.2   Document FUTEX_LOCK_PI2

* ioctl_tty.2   Document ioctls: TCGETS2, TCSETS2, TCSETSW2, TCSETSF2

* pidfd_open.2  Document PIDFD_NONBLOCK

* seccomp_unotify.2 Document SECCOMP_ADDFD_FLAG_SEND

* sigaction.2   Document SA_EXPOSE_TAGBITS and the flag support detection 
protocol

* statx.2   Document STATX_MNT_ID
* capabilities.7
* user_namespaces.7 Describe CAP_SETFCAP for mapping UID 0

* mount_namespaces.7More clearly explain the notion of locked mounts
  For a long time, this manual page has had a brief discussion of
  "locked" mounts, without clearly saying what this concept is, or
  why it exists. Expand the discussion with an explanation of what
  locked mounts are, why mounts are locked, and some examples of the
  effect of locking.
* user_namespaces.7 Document /proc/PID/projid_map

* ld.so.8   Document --list-tunables option added in glibc 2.33


Global changes

Few/Various pages:
* ERRORS: correct alphabetic order

* Place SEE ALSO entries in correct order

* Arrange .SH sections in correct order

* Consistently use '*argv[]'

* Fix EBADF error description
  Make the description of the EBADF error for invalid 'dirfd' more
  uniform. In particular, note that the error only occurs when the
  pathname is relative, and that it occurs when the 'dirfd' is
  neither valid *nor* has the value AT_FDCWD.

* ERRORS: combine errors into a single alphabetic list
  These pages split out extra errors for some APIs into a separate
  list.  Probably, the pages are easier to read if all errors are
  combined into a single list.

  Note that there still remain a few pages where the errors are
  listed separately for different APIs. For the moment, it seems
  best to leave those pages as is, since the error lists are
  largely distinct in those pages.

* Terminology clean-up: "mount point" ==> "mount"
  Many times, these pages use the terminology "mount point", where
  "mount" would be better. A "mount point" is the location at which a
  mount is attached. A "mount" is an association between a filesystem
  and a mount point.

* accept.2
* access.2
* getpriority.2
* mlock.2
  ERRORS: combine errors into a single list
  These pages split out errors into separate lists (perhaps per API,
  perhaps "may" vs "shall", perhaps "Linux-specific" vs standard(??)),
  but there's no good reason to do this.  It makes the error list harder
  to read, and is inconsistent with other pages. So, combine the errors
  into a single list.

* fanotify_mark.2
* futimesat.2
* mount_setattr.2
* statx.2
* symlink.2
* mkfifo.3
  Refer the reader to openat(2) for explanation of why 'dirfd' is useful


Changes to individual pages

* iconv.1
* iconvconfig.8
  FILES: note that files may be under /usr/lib64 rather than /lib/64

* ldd.1 Fix example command

* add_key.2
* keyctl.2
* request_key.2
  Note that the "libkeyutils" package provides 

* close_range.2 Glibc 2.34 has added a close_range() wrapper

* execve.2  The pathname given to interpreter is not necessarily absolute
  SEE ALSO: getauxval(3)
  getauxval(3) is useful background regarding execve(2).

* fanotify_mark.2   ERRORS: add missing EBADF error for invalid 'dirfd'

* ioctl_tty.2   Update DTR example
  D

Re: Package Requests: Update: bash-completion, coreutils - New: linux-manpages

[Brian Inglis]

On 2021-08-13 14:48, Richard Beels via Cygwin wrote:
At 8/13/2021 at 01:11, Shakespearean monkeys danced on Brian Inglis's 
keyboard and said:
 I suggested linux-manpages a while back, as it comes from the same 
source as posix-manpages, and I install it myself, but did not get 
voted to package, due to duplication with conflicting priorities and 
no easy way to resolve under existing paths.


Huh...  they go to /usr/local by default (easily changeable with `make 
prefix=...`), which is pretty bare to begin with and with the fact that 
they don't package hardly anything in man1, the conflict potential goes 
down even further.  Ah well, I guess I just keep making it manually from 
a cloned repo.


That's the issue - Cygwin supports project man pages installed under FHS 
locations like /usr/share/man/ where there would be "duplication", not 
installing in non-standard locations under /usr/local/{share/,}man/ nor 
under /usr/share/man/linux/ (man -m linux)!


 I could probably look at bash-completion if I can get around to bash, 
as I would worry about dependencies, fixes, and tweaks. There are big 
challenges in bash and coreutils being years out of date as parts of 
those need customized for Cygwin, and the customization patches are 
likely to have issues, or even need redesign, if there have been major 
changes.


bash-completion is a separate/disconnected project (now located at 
https://github.com/scop/bash-completion), it doesn't align its releases 
with bash itself.  bash-completion 2.7-2.10 require bash 4.1+, 2.11 
bumped that to 4.2.  Since we're at 4.4, I don't think that's a 
showstopper (BICBW).


BYCBC|BYCBR

And thanks again for the findutils update.  4.7 gave us comma-delimited 
-type/-xtype specs, so a "( -type p -o -type s )" (shown non-quoted for 
sanity's sake) becomes "-type p,s".  :thumbsup:


--
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: Package Requests: Update: bash-completion, coreutils - New: linux-manpages

[Richard Beels via Cygwin]

At 8/13/2021 at 01:11, Shakespearean monkeys danced on Brian Inglis's 
keyboard and said:
 I suggested linux-manpages a while back, as it comes from the same 
source as posix-manpages, and I install it myself, but did not get 
voted to package, due to duplication with conflicting priorities 
and no easy way to resolve under existing paths.


Huh...  they go to /usr/local by default (easily changeable with 
`make prefix=...`), which is pretty bare to begin with and with the 
fact that they don't package hardly anything in man1, the conflict 
potential goes down even further.  Ah well, I guess I just keep 
making it manually from a cloned repo.



 I could probably look at bash-completion if I can get around to 
bash, as I would worry about dependencies, fixes, and tweaks. There 
are big challenges in bash and coreutils being years out of date as 
parts of those need customized for Cygwin, and the customization 
patches are likely to have issues, or even need redesign, if there 
have been major changes.


bash-completion is a separate/disconnected project (now located at 
https://github.com/scop/bash-completion), it doesn't align its 
releases with bash itself.  bash-completion 2.7-2.10 require bash 
4.1+, 2.11 bumped that to 4.2.  Since we're at 4.4, I don't think 
that's a showstopper (BICBW).




And thanks again for the findutils update.  4.7 gave us 
comma-delimited -type/-xtype specs, so a "( -type p -o -type s )" 
(shown non-quoted for sanity's sake) becomes "-type p,s".  :thumbsup:



--
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: Package Requests: Update: bash-completion, coreutils - New: linux-manpages

[Brian Inglis]

On 2021-08-12 22:20, Richard Beels via Cygwin wrote:
Findutils _was_ on this list but then I saw it come over the transom 
(yeay Brian! :-), which reminded me I never actually wrote about it.  
Procrastination ekes a minor victory...  :)


bash-completion and coreutils are both currently several releases/years 
behind.


Also, I'll throw in an oddball request to save a bucket of headers - 
linux manpages.  I see the posix ones are packaged for the cyg, it would 
be nice to also get the linux manpages packaged in similar fashion.


Cheers - glad those are helping some - looking at a few others right now 
for this weekend:

- bison m4 sed​ - as current - and they are more developer oriented;
- dash grep gzip readline - as test - they are more pervasive and issues 
would be high impact.


I suggested linux-manpages a while back, as it comes from the same 
source as posix-manpages, and I install it myself, but did not get voted 
to package, due to duplication with conflicting priorities and no easy 
way to resolve under existing paths.


I could probably look at bash-completion if I can get around to bash, as 
I would worry about dependencies, fixes, and tweaks.


There are big challenges in bash and coreutils being years out of date 
as parts of those need customized for Cygwin, and the customization 
patches are likely to have issues, or even need redesign, if there have 
been major changes.


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

Package Requests: Update:bash-completion, coreutils - New: linux-manpages

[Richard Beels via Cygwin]

Findutils _was_ on this list but then I saw it come over the transom 
(yeay Brian! :-), which reminded me I never actually wrote about 
it.  Procrastination eekes a minor victory...  :)


bash-completion and coreutils are both currently several releases/years behind.

Also, I'll throw in an oddball request to save a bucket of headers - 
linux manpages.  I see the posix ones are packaged for the cyg, it 
would be nice to also get the linux manpages packaged in similar fashion.



--
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: Ssh key sync problems between linux server and windows server

[Stephen Carrier]

On Mon, Aug 02, 2021 at 10:08:58AM +0200, Roberto Sabelli via Cygwin wrote:
> Hi everyone, I have this problem that I can't solve:
> 
> I have a linux server (Red Hat Enterprise Linux 6 64bit) and a Windows
> server (Windows Server 2016 Datacenter).
> CYGWIN v. 1.5.22 is installed on the Windows server.
> If I make an SSH connection between the Linux server and the Windows server
> and I try to copy a file from the linux machine to the windows machine
> everything works. If I restart the Windows server and try to connect and to
> copy a file again I get this error:
> 
> *+ ssh username@linuxserver '[ -d /cygdrive/c/pippo/pluto/gio/DS ]’*
> *+ '[' 66 -eq 0 ']’*
> *+ echo '[ERROR] Folder /cygdrive/c/pippo/pluto/gio/DS doesn't exist’*

I don't understand what I'm looking at.  Can you come up with a simple
test case?  Why do the lines end with '*'?  Echoing an 'error message'
will produce an error message but isn't really an error.  I think
folks are baffled.

Reduce to simple test case. 
(such as testing existence of remote directory and nothing else.)
What is the command?
What is the response to the command?

--Stephen

-- 
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 key sync problems between linux server and windows server

[Roberto Sabelli via Cygwin]

Hi everyone, I have this problem that I can't solve:

I have a linux server (Red Hat Enterprise Linux 6 64bit) and a Windows
server (Windows Server 2016 Datacenter).
CYGWIN v. 1.5.22 is installed on the Windows server.
If I make an SSH connection between the Linux server and the Windows server
and I try to copy a file from the linux machine to the windows machine
everything works. If I restart the Windows server and try to connect and to
copy a file again I get this error:

*+ ssh username@linuxserver '[ -d /cygdrive/c/pippo/pluto/gio/DS ]’*
*+ '[' 66 -eq 0 ']’*
*+ echo '[ERROR] Folder /cygdrive/c/pippo/pluto/gio/DS doesn't exist’*

The problem persists for some time (it can be minutes or hours) then as if
by magic it resolves itself and everything works again.

It seems that the ssh session opens correctly but cannot find the path in
the Windows machine but I assure you it exists.

This happens every time the Windows server restarts or even just the CYGWIN
sshd service.

Do you have any ideas to help me?

Thank you all for the support.

Roberto

-- 
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: cfsetspeed is not consistent with Linux

[Corinna Vinschen via Cygwin]

On Jul 11 12:33, Ken Brown via Cygwin wrote:
> While investigating an emacs bug
> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49524), I noticed a
> difference in the behavior of cfsetspeed(3) on Cygwin and Linux.  I'm not
> sure we should "fix" this, because Cygwin's behavior is consistent with the
> Linux man page, and Linux's behavior is not.  But I thought I should point
> it out for the sake of discussion, because Cygwin generally tries to emulate
> Linux.  Here are the details:
> 
> The Linux man page for cfsetspeed(3) specifies that the speed argument must
> be one of the constants Bnnn (e.g., B9600) defined in termios.h.  But Linux
> in fact allows the speed to be the numerical baud rate (e.g., 9600).  Test
> case:
> [...]
> $ ./a.out
> Calling cfsetspeed with speed B9600
> cfgetispeed reports speed 13
> Calling cfsetspeed with speed 9600
> cfgetispeed reports speed 13
> 
> On Cygwin, however, the output of the same program is:
> 
> $ ./a
> Calling cfsetspeed with speed B9600
> cfgetispeed reports speed 13
> Calling cfsetspeed with speed 9600
> cfsetspeed: Invalid argument
> 
> If we decide that Cygwin should emulate Linux here, it would be a simple
> matter to copy the glibc code, which checks whether the speed is a numerical
> baud rate and, if so, converts it to a Bnnn constant.

We can do this too.  For historical reasons we should stay careful
taking over other GPLed code into the Cygwin DLL itself, but just
copying the speed_struct struct should be fine.


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

cfsetspeed is not consistent with Linux

[Ken Brown via Cygwin]

While investigating an emacs bug 
(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49524), I noticed a difference in 
the behavior of cfsetspeed(3) on Cygwin and Linux.  I'm not sure we should "fix" 
this, because Cygwin's behavior is consistent with the Linux man page, and 
Linux's behavior is not.  But I thought I should point it out for the sake of 
discussion, because Cygwin generally tries to emulate Linux.  Here are the details:


The Linux man page for cfsetspeed(3) specifies that the speed argument must be 
one of the constants Bnnn (e.g., B9600) defined in termios.h.  But Linux in fact 
allows the speed to be the numerical baud rate (e.g., 9600).  Test case:


$ cat cfsetspeed_test.c
#include 
#include 

int
main ()
{
  struct termios tp;

  printf ("Calling cfsetspeed with speed B9600\n");
  if (cfsetspeed (&tp, B9600) < 0)
perror ("cfsetspeed");
  else
printf ("cfgetispeed reports speed %u\n", cfgetispeed (&tp));
  printf ("Calling cfsetspeed with speed 9600\n");
  if (cfsetspeed (&tp, 9600) < 0)
perror ("cfsetspeed");
  else
printf ("cfgetispeed reports speed %u\n", cfgetispeed (&tp));
}

$ gcc cfsetspeed_test.c

$ ./a.out
Calling cfsetspeed with speed B9600
cfgetispeed reports speed 13
Calling cfsetspeed with speed 9600
cfgetispeed reports speed 13

On Cygwin, however, the output of the same program is:

$ ./a
Calling cfsetspeed with speed B9600
cfgetispeed reports speed 13
Calling cfsetspeed with speed 9600
cfsetspeed: Invalid argument

If we decide that Cygwin should emulate Linux here, it would be a simple matter 
to copy the glibc code, which checks whether the speed is a numerical baud rate 
and, if so, converts it to a Bnnn constant.


Ken

--
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: blockdev.exe is missing in util-linux. How to determine block device size in bash?

[Duncan Roe]

On Sat, Dec 05, 2020 at 12:43:25PM +0300, cygwin wrote:
> Strange. On Win7 this doesn't work:
>
> il@mar2 /cygdrive/c/Windows/System32
> $ cat /proc/partitions
> major minor  #blocks  name   win-mounts
>
> 8 0 0 sda
> 816 0 sdb
>
> il@mar2 /cygdrive/c/Windows/System32
> $ dd of=/dev/null if=/dev/sda bs=1M count=100
> 100+0 records in
> 100+0 records out
> 104857600 bytes (105 MB, 100 MiB) copied, 0.215181 s, 487 MB/s
>
>
> On 28.11.2020 20:04, Brian Inglis wrote:
> > $ cat /proc/partitions
> > major minor  #blocks  name   win-mounts
> >
> > 8 0 976762584 sda
> > 8 1 16384 sda1
> > 8 2 97678 sda2   C:\
> > 816 976762584 sdb
> > 817131072 sdb1
> > 818102400 sdb2
> > 819 975482161 sdb3   D:\
> > 820577536 sdb4
> > 821465920 sdb5
> > 832 0 sdc

WFFM with Win7 Home

12:34:05$ cat /proc/partitions
major minor  #blocks  name   win-mounts

8 0 488386584 sda
8 1203776 sda1
8 2 467246080 sda2   C:\
8 3  20829184 sda3   D:\
8 4105472 sda4   F:\

Cheers ... Duncan.
--
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: blockdev.exe is missing in util-linux. How to determine block device size in bash?

[Ilya Basin via Cygwin]

Strange. On Win7 this doesn't work:

il@mar2 /cygdrive/c/Windows/System32
$ cat /proc/partitions
major minor  #blocks  name   win-mounts

8 0 0 sda
816 0 sdb

il@mar2 /cygdrive/c/Windows/System32
$ dd of=/dev/null if=/dev/sda bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.215181 s, 487 MB/s


On 28.11.2020 20:04, Brian Inglis wrote:
> $ cat /proc/partitions
> major minor  #blocks  name   win-mounts
> 
> 8 0 976762584 sda
> 8 1 16384 sda1
> 8 2 97678 sda2   C:\
> 816 976762584 sdb
> 817131072 sdb1
> 818102400 sdb2
> 819 975482161 sdb3   D:\
> 820577536 sdb4
> 821465920 sdb5
> 832 0 sdc
--
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: blockdev.exe is missing in util-linux. How to determine block device size in bash?

[Brian Inglis]

On 2020-11-28 01:08, Basin Ilya via Cygwin wrote:
Actually I have nothing to add to the subject. blockdev.exe missing in 
util-linux. How to determine block device size in bash?

$ cat /proc/partitions
major minor  #blocks  name   win-mounts

8 0 976762584 sda
8 1 16384 sda1
8 2 97678 sda2   C:\
816 976762584 sdb
817131072 sdb1
818102400 sdb2
819 975482161 sdb3   D:\
820577536 sdb4
821465920 sdb5
832 0 sdc

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

blockdev.exe is missing in util-linux. How to determine block device size in bash?

[Basin Ilya via Cygwin]

Hi list. 
Actually I have nothing to add to the subject. blockdev.exe missing in 
util-linux. How to determine block device size in bash?
--
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: Is it possible to vnc into a linux guest?

[Jim McNamara via Cygwin]

On Wed, Sep 23, 2020, 5:12 PM René Berber via Cygwin 
wrote:

> On 9/23/2020 1:07 PM, Jim McNamara via Cygwin wrote:
>
> > I tried to use tigervnc to connect to a linux virtualbox guest from
> cygwin.
>
> Those 3 things are independent, i.e. there's no VNC in Cygwin (OK there
> is, but you don't need it... and installing an X server just for that is
> overkill), and there's no VNC in a Linux virtualbox unless it is running
> the VNC server.
>

 I didn't know all this cool info.

>
 It (the guest) is running the vnc server

> I am not sure it is possible after many attempts.
>
> Of course its possible.  You are just going at it the wrong way.
>
> > I did have ssh working and x forwarding of smallish APPS.
>
> Irrelevant.  You don't need any of those.


> Just follow the VNC guide, its simple, you need a client (tigerVNC --
> there's a version for Windows) and a server, then you need to know which
> IP address and port to use, maybe open those ports on firewalls.
>

> R. Berber
>

   Thanks R.
Jim.  :-)

> 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: https://cygwin.com/ml/#unsubscribe-simple

Re: Is it possible to vnc into a linux guest?

[René Berber via Cygwin]

On 9/23/2020 1:07 PM, Jim McNamara via Cygwin wrote:


I tried to use tigervnc to connect to a linux virtualbox guest from cygwin.


Those 3 things are independent, i.e. there's no VNC in Cygwin (OK there 
is, but you don't need it... and installing an X server just for that is 
overkill), and there's no VNC in a Linux virtualbox unless it is running 
the VNC server.



I am not sure it is possible after many attempts.


Of course its possible.  You are just going at it the wrong way.


I did have ssh working and x forwarding of smallish APPS.


Irrelevant.  You don't need any of those.

Just follow the VNC guide, its simple, you need a client (tigerVNC -- 
there's a version for Windows) and a server, then you need to know which 
IP address and port to use, maybe open those ports on firewalls.

--
R.Berber
--
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

Is it possible to vnc into a linux guest?

[Jim McNamara via Cygwin]

Hi all-

I tried to use tigervnc to connect to a linux virtualbox guest from cygwin.

I am not sure it is possible after many attempts.

I did have ssh working and x forwarding of smallish APPS.

Thanks for any insight.

Roboloki
--
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: Linux

[cygwinautoreply--- via Cygwin]

>1 [main] ssh 11260 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer
>The information contained in this message is proprietary and/or confidential. 
>If you are not the intended recipient, please: (i) delete the message and all 
>copies; (ii) do not disclose, distribute or use the message in any manner; and 
>(iii) notify the sender immediately. In addition, please be aware that any 
>message addressed to our domain is subject to archiving and review by persons 
>other than the intended recipient. Thank you.

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

Linux

[Zektser, Michael P via Cygwin]

1 [main] ssh 11260 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.
--
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: setting up a cygwin cross compiler on linux

[Corinna Vinschen]

On Jul 27 22:52, marty leisner via Cygwin wrote:
> I want to cross compile cygwin programs on linux.
> 
> I vaguely recall there was a debian package for this years ago.   No luck
> now.
> 
> All my web searches talk about cross compiling on cygwin for linux.
> 
> I wonder if there's a pre-assembled kit to do this (i.e. include files,
> libraries, and specs file)

Yaakov maintains a repository for Fedora with Cygwin cross compilation
stuff:

  https://copr.fedorainfracloud.org/coprs/yselkowitz/cygwin/


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

setting up a cygwin cross compiler on linux

[marty leisner via Cygwin]

I want to cross compile cygwin programs on linux.

I vaguely recall there was a debian package for this years ago.   No luck
now.

All my web searches talk about cross compiling on cygwin for linux.

I wonder if there's a pre-assembled kit to do this (i.e. include files,
libraries, and specs file)

marty
--
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: util-linux 2.33.1-2

[Mark Geisert]

The following packages have been uploaded to the Cygwin distribution:

* util-linux-2.33.1-2
* libblkid1-2.33.1-2
* libblkid-devel-2.33.1-2
* libfdisk1-2.33.1-2
* libfdisk-devel-2.33.1-2
* libsmartcols1-2.33.1-2
* libsmartcols-devel-2.33.1-2
* libuuid1-2.33.1-2
* libuuid-devel-2.33.1-2
* uuidd-2.33.1-2

This is a re-spin of Cygwin's current util-linux release 2.33.1 that
adds a 'taskset' executable.  Taskset takes advantage of the recent
addition of cpu affinity support to Cygwin.  It allows one to assign
Cygwin processes to a specific cpu or cpus.

I'd like to thank Cygwin user Eliot Moss for his encouragement in
getting cpu affinity support added to Cygwin, and his patches that
made possible the clean building of this util-linux update.

Questions and/or comments to the Cygwin mailing list please:
cygwin (at) cygwin (dot) com

..mark
--
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: Linux compiling in kernel

[Yaakov Selkowitz]

On Wed, 2020-04-08 at 15:18 +0530, vishnu via Cygwin wrote:
> I have installed cygwin.
> I am trying to compile linux kernel.It is for x86 platform.
> But When I give below command:
> #make
>  CC  scripts/mod/empty.o
> cc1: error: code model kernel does not support PIC mode
> make[1]: *** [scripts/Makefile.build:268: scripts/mod/empty.o] Error 1
> make: *** [Makefile:1116: prepare0] Error 2
> 
> This error iam facing.
> Can you please help me.
> 
> Your help is highly appreciated.

https://sourceware.org/legacy-ml/cygwin/2012-06/msg00221.html

--
Yaakov


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

Linux compiling in kernel

[vishnu via Cygwin]

Hi Team,

I have installed cygwin.
I am trying to compile linux kernel.It is for x86 platform.
But When I give below command:
#make
 CC  scripts/mod/empty.o
cc1: error: code model kernel does not support PIC mode
make[1]: *** [scripts/Makefile.build:268: scripts/mod/empty.o] Error 1
make: *** [Makefile:1116: prepare0] Error 2

This error iam facing.
Can you please help me.

Your help is highly appreciated.

Thank you,
Vishnu
--
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: Why is taskset still not in util-linux?

[Eliot Moss]

On 3/24/2020 4:09 AM, Mark Geisert wrote:

Eliot Moss wrote:

Well, I had _thought_ I had done 'cygport install' and run the installed
version, but I seem to have been wrong.  I seem to have manually over-written
the proper (stripped) binary with the wrapper!

Anyway, I've got the whole thing working and offer the attached patches for
"thoughtful consideration".  I have done away with the need to create an empty
or fake /usr/local/include/sys/syscall.h and changed the source of the
relevant programs to conditional #include  on #indef
__CYGWIN__, which sruck me as more legitimate (the file in questions is
patched anyway).  And I improved configure.ac so that the programs controlled
by --enable-schedutils are more independent and can fail individually without
failing the build.  Part of that was subtituting, as a patch to configure.ac,
a check for the sched_getaffinity and sched_setaffinity calls in place of the
check for the corresponding syscall.  The whole builds and installs.  I can
provide the packaged up version (I assume that is the 'dist' hierarchy) if
that would be helpful.


Thanks very much for working on all this and contributing it.  I will build and test as soon as I 
can.  I need to research the packaging steps because I intend to ITA this package.  I do also want 
to take another look at the other programs built as part of --enable-schedutils; they might (or 
might not) build cleanly but AFAIK there's no support within Cygwin and/or Windows for what they can 
do on Linux.


Agreed - glad to help!   Eliot
--
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: Why is taskset still not in util-linux?

[Mark Geisert]

Eliot Moss wrote:

Well, I had _thought_ I had done 'cygport install' and run the installed
version, but I seem to have been wrong.  I seem to have manually over-written
the proper (stripped) binary with the wrapper!

Anyway, I've got the whole thing working and offer the attached patches for
"thoughtful consideration".  I have done away with the need to create an empty
or fake /usr/local/include/sys/syscall.h and changed the source of the
relevant programs to conditional #include  on #indef
__CYGWIN__, which sruck me as more legitimate (the file in questions is
patched anyway).  And I improved configure.ac so that the programs controlled
by --enable-schedutils are more independent and can fail individually without
failing the build.  Part of that was subtituting, as a patch to configure.ac,
a check for the sched_getaffinity and sched_setaffinity calls in place of the
check for the corresponding syscall.  The whole builds and installs.  I can
provide the packaged up version (I assume that is the 'dist' hierarchy) if
that would be helpful.


Thanks very much for working on all this and contributing it.  I will build and 
test as soon as I can.  I need to research the packaging steps because I intend 
to ITA this package.  I do also want to take another look at the other programs 
built as part of --enable-schedutils; they might (or might not) build cleanly 
but AFAIK there's no support within Cygwin and/or Windows for what they can do 
on Linux.


Thanks again,

..mark

--
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: Why is taskset still not in util-linux?

[Brian Inglis]

On 2020-03-23 03:42, Mark Geisert wrote:
> Corinna Vinschen wrote:
>> On Mar 21 10:41, Brian Inglis wrote:
>>> On 2020-03-21 02:18, Mark Geisert wrote:
 Eliot Moss wrote:
> On 3/20/2020 1:54 AM, Mark Geisert wrote:
>> I've reproduced your snags. It/they are due to my having forgotten
>> another tiny update that should have been part of the
>> 2.33.1-cygwin-cpuset.patch file.  If you
>> 'echo "#define SYS_sched_getaffinity 42" > 
>> /usr/local/include/sys/syscall.h'
>> and then back out your other fix attempts, the build using cygport should
>> work.
> Once I did that properly, it built without commenting out that test. Yay!
>>>
 I ended up installing Process Lasso to follow processes among the cpus and 
 to
 test the Cygwin affinity mask implementation.  It has a free trial period. 
  And
 I wrote a simple test program that just advances from one cpu to the next
 repeatedly, cpu-bound between steps, so PL can display the changing cpu.
>>>
>>> Anyone know if this feature support or what feature support will get top 
>>> P/last
>>> used CPU and/or procps-ng P/sgi_p currently executing CPU and PSR/currently
>>> assigned CPU showing actual CPUs rather than 0/zero?
>>>
>>> Anyone know if or where or how this info is available on Windows or a link 
>>> to
>>> it? I've looked at Google and SO results and nothing useful is apparent.
>>
>> Can't we just fake the calls?

The results are currently faked to CPU # 0.

> Brian is asking for a way to watch processes globally, as they are scheduled
> back and forth on the available cpus.  I was a bit sloppy in my wording above;
> what Process Lasso displays is the changing process affinity mask for a 
> process
> I wrote to do just that.  I don't know of a way to ask Windows which cpu a
> process is currently scheduled onto.

You can also get and set affinity in Task Manager, and also ideal CPU info using
SysInternals Process Explorer, or PowerShell, which I use to launch Windows ntpd
at max realtime priority on CPU `nproc` - 1, as CMD arithmetic was nonexistent
or obscure years ago. I could probably redo that with CMD start.

Only documented CPU # call I could find was GetCurrentProcessorNumber (-Ex also
returns processor group) which tells the current thread where it's executing,
not the last or current CPU # assigned or used for other process threads.

-- 
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.
--
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: Why is taskset still not in util-linux?

[Mark Geisert]

Corinna Vinschen wrote:

On Mar 21 10:41, Brian Inglis wrote:

On 2020-03-21 02:18, Mark Geisert wrote:

Eliot Moss wrote:

On 3/20/2020 1:54 AM, Mark Geisert wrote:

I've reproduced your snags. It/they are due to my having forgotten
another tiny update that should have been part of the
2.33.1-cygwin-cpuset.patch file.  If you
'echo "#define SYS_sched_getaffinity 42" > /usr/local/include/sys/syscall.h'
and then back out your other fix attempts, the build using cygport should
work.

Once I did that properly, it built without commenting out that test. Yay!



I ended up installing Process Lasso to follow processes among the cpus and to
test the Cygwin affinity mask implementation.  It has a free trial period.  And
I wrote a simple test program that just advances from one cpu to the next
repeatedly, cpu-bound between steps, so PL can display the changing cpu.


Anyone know if this feature support or what feature support will get top P/last
used CPU and/or procps-ng P/sgi_p currently executing CPU and PSR/currently
assigned CPU showing actual CPUs rather than 0/zero?

Anyone know if or where or how this info is available on Windows or a link to
it? I've looked at Google and SO results and nothing useful is apparent.


Can't we just fake the calls?


Brian is asking for a way to watch processes globally, as they are scheduled 
back and forth on the available cpus.  I was a bit sloppy in my wording above; 
what Process Lasso displays is the changing process affinity mask for a process 
I wrote to do just that.  I don't know of a way to ask Windows which cpu a 
process is currently scheduled onto.


..mark
--
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: Why is taskset still not in util-linux?

[Corinna Vinschen]

On Mar 21 10:41, Brian Inglis wrote:
> On 2020-03-21 02:18, Mark Geisert wrote:
> > Eliot Moss wrote:
> >> On 3/20/2020 1:54 AM, Mark Geisert wrote:
> >>> I've reproduced your snags. It/they are due to my having forgotten 
> >>> another tiny update that should have been part of the 
> >>> 2.33.1-cygwin-cpuset.patch file.  If you
> >>> 'echo "#define SYS_sched_getaffinity 42" > 
> >>> /usr/local/include/sys/syscall.h' 
> >>> and then back out your other fix attempts, the build using cygport should
> >>> work.
> >> Once I did that properly, it built without commenting out that test. Yay!
> 
> > I ended up installing Process Lasso to follow processes among the cpus and 
> > to
> > test the Cygwin affinity mask implementation.  It has a free trial period.  
> > And
> > I wrote a simple test program that just advances from one cpu to the next
> > repeatedly, cpu-bound between steps, so PL can display the changing cpu.
> 
> Anyone know if this feature support or what feature support will get top 
> P/last
> used CPU and/or procps-ng P/sgi_p currently executing CPU and PSR/currently
> assigned CPU showing actual CPUs rather than 0/zero?
> 
> Anyone know if or where or how this info is available on Windows or a link to
> it? I've looked at Google and SO results and nothing useful is apparent.

Can't we just fake the calls?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP 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: Why is taskset still not in util-linux?

[Yaakov Selkowitz]

On Sat, 2020-03-21 at 01:37 -0700, Mark Geisert wrote:
> Eliot Moss wrote:
> > On 3/20/2020 9:39 AM, Yaakov Selkowitz wrote:
> > 
> >  > Cygwin doesn't support syscalls.  I'd be very wary of any code which is
> >  > conditional on any #ifdef SYS_*.
> > 
> > Of course.  AFAICT taskset does not need the syscall, it just needs the
> > library call to work.  Asking about the syscall is, I suppose, a kind of 
> > Linux
> > shorthand to see if something is supported on the particular platform.  
> > Mark's
> > suggestion of providing a fake definition of that syscall definition is a
> > workaround that may disturb the util-linux sources the least.
> 
> What I did here was definitely a hack.  I'm not sure it's the best solution.
> 
> I fully concur with Yaakov's warning.  There's two levels to syscalls as seen 
> in 
> programs like taskset.  On one level, configure checks whether a particular 
> syscall exists on the compiling machine because different Linux kernels have 
> different sets of syscalls.  On the second level, the program actually uses a 
> call named syscall() to call into specific kernel routines.
> 
> On Cygwin, what to do about programs that assume they're running on Linux and 
> so 
> make use of the Linux syscall feature?  We could dummy up a sys/syscall.h but 
> implementing a full syscall() interface would be a lot of work and do nothing 
> but slow down programs making heavy use of it; it adds a layer of indirection.

I have considered doing just that on multiple occasions, but never got
so desperate for it to bother.  Keep in mind that kernel APIs often
vary from their userspace wrappers (which is one of the two reasons
userspace code calls syscall, the other being to access yet-unwrapped
calls), meaning such an implementation wouldn't be a simple mapping to
existing userspace functions.  However, I wouldn't worry so much about
performance, the point would be compatibility.

> Yaakov, do you have a general strategy for dealing with syscall usage when 
> you've come across it in all the porting you've done?  Cygwin-specific patch?

That depends very much on what the code is trying to do (and which
syscalls it wants to call!), but using #ifdef SYS_* to guard use of the
corresponding userspace function call might be a first.  There are
definitely some of my packages which I had to patch around syscall
assumptions, but I'd have to go find them.

--
Yaakov

--
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: Why is taskset still not in util-linux?

[Eliot Moss]

PS - The same patches work fine for a 32-bit build (I just test it).  Again, I
can supply the package files if desired.

Regards - EM
--
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: Why is taskset still not in util-linux?

[Eliot Moss]

Well, I had _thought_ I had done 'cygport install' and run the installed
version, but I seem to have been wrong.  I seem to have manually over-written
the proper (stripped) binary with the wrapper!

Anyway, I've got the whole thing working and offer the attached patches for
"thoughtful consideration".  I have done away with the need to create an empty
or fake /usr/local/include/sys/syscall.h and changed the source of the
relevant programs to conditional #include  on #indef
__CYGWIN__, which sruck me as more legitimate (the file in questions is
patched anyway).  And I improved configure.ac so that the programs controlled
by --enable-schedutils are more independent and can fail individually without
failing the build.  Part of that was subtituting, as a patch to configure.ac,
a check for the sched_getaffinity and sched_setaffinity calls in place of the
check for the corresponding syscall.  The whole builds and installs.  I can
provide the packaged up version (I assume that is the 'dist' hierarchy) if
that would be helpful.

Regards - Eliot
NAME="util-linux"
VERSION=2.33.1
RELEASE=1
CATEGORY="Base"
SUMMARY="Collection of basic system utilities"
HOMEPAGE="https://github.com/karelzak/util-linux/";
SRC_URI="https://mirrors.edge.kernel.org/pub/linux/utils/${NAME}/v${PV_MAJ_MIN}/${NAME}-${VERSION}.tar.xz";
PATCH_URI="
2.24.2-libintl.patch
2.25.1-cygwin-include.patch
2.24.2-agetty.patch
2.24.2-libblkid-topology.patch
2.32.1-testsuite.patch
2.33.1-cygwin-cpuset.patch
2.33.1-cygwin-cpuset.patch2
2.33.1-cygwin-ionice.patch
2.33.1-cygwin-taskset.patch
"

PKG_NAMES="${NAME} libblkid1 libblkid-devel libfdisk1 libfdisk-devel
   libsmartcols1 libsmartcols-devel libuuid1 libuuid-devel uuidd"
util_linux_CONTENTS="
--exclude=*.dll --exclude=uuidd*
bin/*
sbin/*
usr/bin/*
usr/share/bash-completion/
usr/share/doc/${NAME}
usr/share/locale/*/*/util-linux.mo
usr/share/man/man[158]/*
"
libblkid1_CATEGORY="Libs"
libblkid1_SUMMARY="Block device ID library (runtime)"
libblkid1_CONTENTS="usr/bin/cygblkid-1.dll"
libblkid_devel_CATEGORY="Libs"
libblkid_devel_SUMMARY="Block device ID library (development)"
libblkid_devel_CONTENTS="
usr/include/blkid/
usr/lib/libblkid.*
usr/lib/pkgconfig/blkid.pc
usr/share/man/man3/*blkid*
"
libfdisk1_CATEGORY="Libs"
libfdisk1_SUMMARY="Disk partition table manipulation library (runtime)"
libfdisk1_CONTENTS="usr/bin/cygfdisk-1.dll"
libfdisk_devel_CATEGORY="Libs"
libfdisk_devel_SUMMARY="Disk partition table manipulation library (development)"
libfdisk_devel_CONTENTS="
usr/include/libfdisk/
usr/lib/libfdisk.*
usr/lib/pkgconfig/fdisk.pc
"
libsmartcols1_CATEGORY="Libs"
libsmartcols1_SUMMARY="Tabular data formatting library (runtime)"
libsmartcols1_DESCRIPTION="The libsmartcols library is used for smart
adaptive formatting of tabular data."
libsmartcols1_CONTENTS="usr/bin/cygsmartcols-1.dll"
libsmartcols_devel_CATEGORY="Libs"
libsmartcols_devel_SUMMARY="Tabular data formatting library (development)"
libsmartcols_devel_DESCRIPTION=${libsmartcols1_DESCRIPTION}
libsmartcols_devel_CONTENTS="
usr/include/libsmartcols/
usr/lib/libsmartcols.*
usr/lib/pkgconfig/smartcols.pc
"
libuuid1_CATEGORY="Libs"
libuuid1_SUMMARY="Universally Unique ID library (runtime)"
libuuid1_CONTENTS="usr/bin/cyguuid-1.dll"
libuuid_devel_CATEGORY="Libs"
libuuid_devel_SUMMARY="Universally Unique ID library (development)"
libuuid_devel_CONTENTS="
usr/include/uuid/
usr/lib/libuuid.*
usr/lib/pkgconfig/uuid.pc
usr/share/man/man3/*uuid*
"
uuidd_CATEGORY="System"
uuidd_SUMMARY="UUID daemon"
uuidd_CONTENTS="
usr/sbin/uuidd.exe
usr/share/bash-completion/completions/uuidd
usr/share/man/man8/uuidd.8*
var/lib/libuuid/
var/run/uuidd/
"

BUILD_REQUIRES="
bison
gettext-devel
libcrypt-devel
libncurses-devel
libreadline-devel
zlib-devel
"

CPPFLAGS+=" -D__USE_LINUX_IOCTL_DEFS"

# fsck: e2fsprogs
# ipcrm, ipcs: ipc-utils
# kill, mount: cygwin
# login: login
# su: coreutils
# last, mesg, mountpoint, utmpdump, wall: sysvinit
# others are linux-specific or obsolete
CYGCONF_ARGS="
  --runstatedir=/var/run
  --enable-libuuid
  --enable-libuuid-force-uuidd
  --enable-libblkid
  --enable-libfdisk
  --disable-libmount
  --disable-mount
  --disable-losetup
  --disable-fsck
  --disable-partx
  --enable-uuidd
  --di

Re: Why is taskset still not in util-linux?

[Eliot Moss]

On 3/21/2020 10:26 AM, Roumen Petrov wrote:
> Eliot Moss wrote:
>> So here's a thing, though I don't understand it:
>>
>> In addition the build/taskset.exe, there's a build/.libs/taskset.exe.
>> If I install the latter in /usr/bin/.libs/taskset.exe, then /usr/bin/taskset
>> works.  In fact, it seems that the version in .libs is the "real" program
>> and /usr/bin/taskset is some kind of trampoline (?) to it?
> Libtool wrapper is shell script on Unix/Linux and executable on Microsoft 
Windows OS. Goal of
> "wrapper" is to prepare environment in the way that allows to run real executable without 
installation.

> Project that creates just one executable is not the beast sample but think 
for a library project and
> a bundle of tests (executable). All tests must load library from build tree.
>
>
>>
>> In fact, a stripped version of build/.libs/taskset installed in /usr/bin
>> works just fine.  There must be some kind of build and install convention
>> going on that I am not familiar with.  (I'm not familiar with a lot of
>> these build processes, actually.)
> I think that in some cases this executable has to be relinked. Definitely not 
on Microsoft Windows
> OS. So on cygwin it is "final" executable.

Thanks - I start to get the picture.  What is odd is that 'cygport install'
puts the _wrapper_ into /usr/bin rather than the executable, and does not
install the exectable.  The wrapper just silently fails.  Now maybe if I built
the package (as if I were the package maintainer) and installed that with
cygwin's setup, I would get the right thing - not sure (and not 100% sure how
to do that).

Cheers - EM
--
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: Why is taskset still not in util-linux?

[Brian Inglis]

On 2020-03-21 02:18, Mark Geisert wrote:
> Eliot Moss wrote:
>> On 3/20/2020 1:54 AM, Mark Geisert wrote:
>>> I've reproduced your snags. It/they are due to my having forgotten 
>>> another tiny update that should have been part of the 
>>> 2.33.1-cygwin-cpuset.patch file.  If you
>>> 'echo "#define SYS_sched_getaffinity 42" > 
>>> /usr/local/include/sys/syscall.h' 
>>> and then back out your other fix attempts, the build using cygport should
>>> work.
>> Once I did that properly, it built without commenting out that test. Yay!

> I ended up installing Process Lasso to follow processes among the cpus and to
> test the Cygwin affinity mask implementation.  It has a free trial period.  
> And
> I wrote a simple test program that just advances from one cpu to the next
> repeatedly, cpu-bound between steps, so PL can display the changing cpu.

Anyone know if this feature support or what feature support will get top P/last
used CPU and/or procps-ng P/sgi_p currently executing CPU and PSR/currently
assigned CPU showing actual CPUs rather than 0/zero?

Anyone know if or where or how this info is available on Windows or a link to
it? I've looked at Google and SO results and nothing useful is apparent.

-- 
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.
--
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: Why is taskset still not in util-linux?

[Roumen Petrov]

Eliot Moss wrote:

So here's a thing, though I don't understand it:

In addition the build/taskset.exe, there's a build/.libs/taskset.exe.
If I install the latter in /usr/bin/.libs/taskset.exe, then /usr/bin/taskset
works.  In fact, it seems that the version in .libs is the "real" program
and /usr/bin/taskset is some kind of trampoline (?) to it?

Libtool wrapper is shell script on Unix/Linux and executable on Microsoft Windows OS. 
Goal of "wrapper" is to prepare environment in the way that allows to run real 
executable without installation.
Project that creates just one executable is not the beast sample but think for 
a library project and a bundle of tests (executable). All tests must load 
library from build tree.




In fact, a stripped version of build/.libs/taskset installed in /usr/bin
works just fine.  There must be some kind of build and install convention
going on that I am not familiar with.  (I'm not familiar with a lot of
these build processes, actually.)

I think that in some cases this executable has to be relinked. Definitely not on 
Microsoft Windows OS. So on cygwin it is "final" executable.




Best - Eliot


Regards,
Roumen
--
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: Why is taskset still not in util-linux?

[Marco Atzeri via Cygwin]

Am 21.03.2020 um 12:07 schrieb Eliot Moss:

So here's a thing, though I don't understand it:

In addition the build/taskset.exe, there's a build/.libs/taskset.exe.


that is usually the unstripped version

If I install the latter in /usr/bin/.libs/taskset.exe, then 
/usr/bin/taskset

works.  In fact, it seems that the version in .libs is the "real" program
and /usr/bin/taskset is some kind of trampoline (?) to it?


it is the libtool wrapper, infact it is linked only to cygwin1.dll


$ objdump -x .libs/gprof.exe | grep "DLL Name"
DLL Name: cygwin1.dll
DLL Name: cygintl-8.dll
DLL Name: KERNEL32.dll

$ objdump -x gprof.exe | grep "DLL Name"
DLL Name: cygwin1.dll
DLL Name: KERNEL32.dll


$ strings gprof.exe | grep ".libs"
./.libs/lt-gprof.c
# gprof - temporary wrapper script for .libs/gprof
...



In fact, a stripped version of build/.libs/taskset installed in /usr/bin
works just fine.  There must be some kind of build and install convention
going on that I am not familiar with.  (I'm not familiar with a lot of
these build processes, actually.)

Best - Eliot


I also forget the details from time to time...

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: Why is taskset still not in util-linux?

[Eliot Moss]

So here's a thing, though I don't understand it:

In addition the build/taskset.exe, there's a build/.libs/taskset.exe.
If I install the latter in /usr/bin/.libs/taskset.exe, then /usr/bin/taskset
works.  In fact, it seems that the version in .libs is the "real" program
and /usr/bin/taskset is some kind of trampoline (?) to it?

In fact, a stripped version of build/.libs/taskset installed in /usr/bin
works just fine.  There must be some kind of build and install convention
going on that I am not familiar with.  (I'm not familiar with a lot of
these build processes, actually.)

Best - Eliot
--
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: Why is taskset still not in util-linux?

[Eliot Moss]

Dear Mark - I am confused by how your build goes through when configure
detects the ionice does not have the ioprio_set/get calls that it needs.  In my
case configure stops at that point.  That was why I made a patch to
configure.ac so that cygport could explicitly exclude ionice.  At the moment,
I am seeing what happens if I add more "fake" syscalls to syscall.h for those
two calls.  The configure goes through (as expected), but of course ionice
fails to link (no 'syscall" function).

If I revert to having only SYS_sched_getaffinity defined, configure stops
with:

checking for syscall ioprio_set... no
configure: WARNING: Unable to detect syscall ioprio_set.
configure: error: ionice selected but ioprio_set syscall not found
*** ERROR: configure failed

That why I think I/we need some kind of patch to configure.ac.  How does
your build manage to continue?

I am working from the Cygwin util-linux-2.33.1-1 source package.  Is that the
correct one?  Also, I am in the x86-64 world for all this.

Eliot
--
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: Why is taskset still not in util-linux?

[Mark Geisert]

Eliot Moss wrote:

On 3/20/2020 9:39 AM, Yaakov Selkowitz wrote:

 > Cygwin doesn't support syscalls.  I'd be very wary of any code which is
 > conditional on any #ifdef SYS_*.

Of course.  AFAICT taskset does not need the syscall, it just needs the
library call to work.  Asking about the syscall is, I suppose, a kind of Linux
shorthand to see if something is supported on the particular platform.  Mark's
suggestion of providing a fake definition of that syscall definition is a
workaround that may disturb the util-linux sources the least.


What I did here was definitely a hack.  I'm not sure it's the best solution.

I fully concur with Yaakov's warning.  There's two levels to syscalls as seen in 
programs like taskset.  On one level, configure checks whether a particular 
syscall exists on the compiling machine because different Linux kernels have 
different sets of syscalls.  On the second level, the program actually uses a 
call named syscall() to call into specific kernel routines.


On Cygwin, what to do about programs that assume they're running on Linux and so 
make use of the Linux syscall feature?  We could dummy up a sys/syscall.h but 
implementing a full syscall() interface would be a lot of work and do nothing 
but slow down programs making heavy use of it; it adds a layer of indirection.


Yaakov, do you have a general strategy for dealing with syscall usage when 
you've come across it in all the porting you've done?  Cygwin-specific patch?


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