Re: fish shell config issue starting 3.6.4 package

2024-01-11 Thread Marco Atzeri via Cygwin 

On 12/01/2024 08:17, Xavier Delaruelle via Cygwin wrote:

Hello,

Since fish shell has been updated to 3.6.4 at the beginning of the year, I
obtain a configuration error:

 fish: Unknown command: pgrep
 /etc/fish/conf.d/01_fish_variables.fish (line 13):
 pgrep fish | grep -v \^$fish_pid\$ | xargs -r kill
 ^~~~^
 from sourcing file /etc/fish/conf.d/01_fish_variables.fish
 called on line 248 of file /usr/share/fish/config.fish
 from sourcing file /usr/share/fish/config.fish
 called during startup

It seems like default fish configuration relies on pgrep which is not found
on Cygwin.

Same issue occurs also with 3.7.0.

Regards,
Xavier



Hi Xavier,
it seems a missing dependency

pgrep is part of procps-ng package

$ cygcheck -p bin/pgrep
Found 10 matches for bin/pgrep
busybox-1.23.2-1 - busybox: Tiny utilities in a single executable
busybox-1.36.1-1 - busybox: Tiny utilities in a single executable
...
procps-ng-4.0.2-2 - procps-ng: System and process monitoring utilities
procps-ng-4.0.3-1 - procps-ng: System and process monitoring utilities
procps-ng-4.0.4-1 - procps-ng: System and process monitoring utilities
procps-3.2.8-5 - procps: Obsoleted by procps-ng


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

fish shell config issue starting 3.6.4 package

2024-01-11 Thread Xavier Delaruelle via Cygwin 
Hello,

Since fish shell has been updated to 3.6.4 at the beginning of the year, I
obtain a configuration error:

fish: Unknown command: pgrep
/etc/fish/conf.d/01_fish_variables.fish (line 13):
pgrep fish | grep -v \^$fish_pid\$ | xargs -r kill
^~~~^
from sourcing file /etc/fish/conf.d/01_fish_variables.fish
called on line 248 of file /usr/share/fish/config.fish
from sourcing file /usr/share/fish/config.fish
called during startup

It seems like default fish configuration relies on pgrep which is not found
on Cygwin.

Same issue occurs also with 3.7.0.

Regards,
Xavier

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

Re: Cygwin tools to read/write NTFS alternate data streams?

2024-01-11 Thread Roland Mainz via Cygwin 
On Thu, Jan 11, 2024 at 5:41 PM Corinna Vinschen via Cygwin
 wrote:
>
> On Jan 11 15:00, Martin Wege via Cygwin wrote:
> > On Mon, Jan 8, 2024 at 3:11 PM Corinna Vinschen via Cygwin
> >  wrote:
> > so this is IMO OK.
>
> Yeah, but...
>
> It's not just an open flag, it requires extending functionality of other
> APIs and, for full support, tools, see
> https://docs.oracle.com/cd/E19253-01/816-5175/6mbba7f02/.
>
> It's also rather weird to call alternate data streams "extended
> attributes", because that's just a small part of streams and it's
> already supported via the Linux functions getxattr(2) and friends, see
> https://man7.org/linux/man-pages/man2/getxattr.2.html
>
> > > Apart from that, this sounds like a nice idea for Cygwin 3.6,
> > > provided somebody implements it, https://cygwin.com/acronyms/#SHTDI
> > >
> > > Assuming we can live without actually having a subdir and just
> > > allowing to open and create a file with the O_XATTR flag, it might be
> > > pretty simple to implement.  The path handling code would just have to
> > > drop the colon from the list of characters converted to the private-use
> > > Unicode area.
> > >
> > > Implementing the subdir is a bit more complicated, especially when
> > > taking opendir/readdir of that virtual subdir into account, but it
> > > would certainly be doable.
> >
> > How do other OSes implement the O_XATTR subdir?
>
> IDK.  But there are a few points we have to keep in mind from the
> Solaris man page:
>
> - Given fd is an open file descriptor,
>
> openat(fd, ".", O_RDONLY|O_XATTR);
>
>   opens the virtual subdir containing the ADS of a file.  It's the
>   only valid way to open the virtual dir.  That's a bit of a relief
>   because it simplifies handling this in openat(2).
>
> openat(fd, "foo", ...|O_XATTR);
>
>   allows to create or open an ADS for an open file fd.
>
> - unlinkat, renameat, fstatat, fchownat, futimesat and fdopendir need to
>   be made ADS-aware.  They only work on ADS if the fd arg already
>   resolves to an ADS, or if fd is the virtual ADS dir of a file and
>   (except in case of fdopendir) the path argument is the name of an
>   existing ADS.
>
> - pathconf needs to support a new flag XATTR_ENABLED.
>
> This can be made to work given the current fhandler framework in Cygwin,
> but again, https://cygwin.com/acronyms/#SHTDI
>
> FTR, I'm generally not a friend of ADS, because they look like a builtin
> security problem.

See below. I'm not 100% happy with that either, but these things
exists in many operating systems, and constantly ignoring them just
because it is not part of POSIX does not serve the users. So far SUN's
Solaris team came up with an API which works with Windows and UNIX
APIs, and it is much better than the alternatives I've seen so far...

> They don't show up in standard directory listings,
> and you can't even see that a file has ADS, except you look for them
> explicitely.  This is a really user-unfriendly interface.

Actually Solaris /usr/bin/ls has option "-@" (basically ls -l plus ADS
support, e.g. ls -l output has an @ displayed after the file
permission bits for files that have alternate data streams).
The plan was to make that the default for ls -l in Solaris 12, but
that plan was ruined by the SUN takeover.

I can make a patch for Cygwin /usr/bin/ls and /usr/bin/find (options
-xattr/-ads) once O_XATTR support is available, and provide an
implementation of runat(1), so people can easily see whether ADS are
around, and access them via runat(1).



Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&& 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

Re: Cygwin tools to read/write NTFS alternate data streams?

2024-01-11 Thread Roland Mainz via Cygwin 
On Thu, Jan 11, 2024 at 3:00 PM Martin Wege via Cygwin
 wrote:
> On Mon, Jan 8, 2024 at 3:11 PM Corinna Vinschen via Cygwin
>  wrote:
> > On Dec 18 18:47, Martin Wege via Cygwin wrote:
> > > On Fri, Dec 1, 2023 at 10:52 AM Corinna Vinschen via Cygwin
> > >  wrote:
[snip]
> > Apart from that, this sounds like a nice idea for Cygwin 3.6,
> > provided somebody implements it, https://cygwin.com/acronyms/#SHTDI
> >
> > Assuming we can live without actually having a subdir and just
> > allowing to open and create a file with the O_XATTR flag, it might be
> > pretty simple to implement.  The path handling code would just have to
> > drop the colon from the list of characters converted to the private-use
> > Unicode area.
> >
> > Implementing the subdir is a bit more complicated, especially when
> > taking opendir/readdir of that virtual subdir into account, but it
> > would certainly be doable.
>
> How do other OSes implement the O_XATTR subdir?

Basically you open a random file or dir with |openat(filename,
O_XATTR)| and get a fd to that (virtual) attribute directory.
The "." in that dir is virtual, but the ".." refers to the underlying
file, so a |open("..", ...)| will return a fd to a file/dir to which
the attributes belong to.

https://illumos.org/man/7/fsattr has the whole API description.

A Windows implementation should be therefore quite easy, as alternate
data streams show up as "foo:stream1", "foo:stream2" etc., so just the
directory lookup needs to be modified to skip the files with ':' in
general, and only show the streams for an O_XATTR subdir, e.g.
|openat("foo", O_XATTR)| would give a dir which lists only Windows
file names which match "foo:*"

I can support such an effort with testing, and a cleanroom
implementation of https://illumos.org/man/1/runat (see
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/runat/runat.c
for the Solaris/Illumos code)



Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.ma...@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&& 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

Re: Cygwin vim + Github Copilot

2024-01-11 Thread Eliot Moss via Cygwin 

On 1/11/2024 8:53 PM, Kevin Schnitzius via Cygwin wrote:

Anyone ever get his working?

I have it working with the win32 version of vim, so I am guessing that the 
forward slash path might might be breaking calls to node.js.

Error I get is:
Copilot: Something unexpected went wrong spawning the agent

I haven't figured out how to debug this yet (don't know vim internals).


I don't use either of these myself, so I'm taking a shot at generic
advice.  Cygwin vim is going to expect to interact with POSIX-like
things using POSIX-like paths.  It's trying to give you a mock up
of a POSIX universe.  Using cygwin programs to call Windows based
tools can quickly get problematic.

A *potential* solution for you is to find and use a Windows vim to
talk with Windows based programs.

Maybe other people have specific knowledge / fixes for you ...

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

Cygwin vim + Github Copilot

2024-01-11 Thread Kevin Schnitzius via Cygwin 
Anyone ever get his working?

I have it working with the win32 version of vim, so I am guessing that the 
forward slash path might might be breaking calls to node.js.

Error I get is:
Copilot: Something unexpected went wrong spawning the agent

I haven't figured out how to debug this yet (don't know vim internals).

Kevin

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

Re: Cygwin tools to read/write NTFS alternate data streams?

2024-01-11 Thread Corinna Vinschen via Cygwin 
On Jan 11 15:00, Martin Wege via Cygwin wrote:
> On Mon, Jan 8, 2024 at 3:11 PM Corinna Vinschen via Cygwin
>  wrote:
> so this is IMO OK.

Yeah, but...

It's not just an open flag, it requires extending functionality of other
APIs and, for full support, tools, see
https://docs.oracle.com/cd/E19253-01/816-5175/6mbba7f02/.

It's also rather weird to call alternate data streams "extended
attributes", because that's just a small part of streams and it's
already supported via the Linux functions getxattr(2) and friends, see
https://man7.org/linux/man-pages/man2/getxattr.2.html

> > Apart from that, this sounds like a nice idea for Cygwin 3.6,
> > provided somebody implements it, https://cygwin.com/acronyms/#SHTDI
> >
> > Assuming we can live without actually having a subdir and just
> > allowing to open and create a file with the O_XATTR flag, it might be
> > pretty simple to implement.  The path handling code would just have to
> > drop the colon from the list of characters converted to the private-use
> > Unicode area.
> >
> > Implementing the subdir is a bit more complicated, especially when
> > taking opendir/readdir of that virtual subdir into account, but it
> > would certainly be doable.
> 
> How do other OSes implement the O_XATTR subdir?

IDK.  But there are a few points we have to keep in mind from the
Solaris man page:

- Given fd is an open file descriptor,

openat(fd, ".", O_RDONLY|O_XATTR);

  opens the virtual subdir containing the ADS of a file.  It's the
  only valid way to open the virtual dir.  That's a bit of a relief
  because it simplifies handling this in openat(2).

openat(fd, "foo", ...|O_XATTR);

  allows to create or open an ADS for an open file fd.

- unlinkat, renameat, fstatat, fchownat, futimesat and fdopendir need to
  be made ADS-aware.  They only work on ADS if the fd arg already
  resolves to an ADS, or if fd is the virtual ADS dir of a file and
  (except in case of fdopendir) the path argument is the name of an
  existing ADS.

- pathconf needs to support a new flag XATTR_ENABLED.

This can be made to work given the current fhandler framework in Cygwin,
but again, https://cygwin.com/acronyms/#SHTDI

FTR, I'm generally not a friend of ADS, because they look like a builtin
security problem.  They don't show up in standard directory listings,
and you can't even see that a file has ADS, except you look for them
explicitely.  This is a really user-unfriendly interface.


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: Cygwin tools to read/write NTFS alternate data streams?

2024-01-11 Thread Martin Wege via Cygwin 
On Mon, Jan 8, 2024 at 3:11 PM Corinna Vinschen via Cygwin
 wrote:
>
> On Dec 18 18:47, Martin Wege via Cygwin wrote:
> > On Fri, Dec 1, 2023 at 10:52 AM Corinna Vinschen via Cygwin
> >  wrote:
> > >
> > > On Nov 30 04:55, Martin Wege via Cygwin wrote:
> > > > Hello,
> > > >
> > > > Does Cygwin have tools (modified /usr/bin/dd ?) to read/write NTFS
> > > > alternate data streams?
> > >
> > > No.  As you know, the colon is translated to a normal filename
> > > character, and there's no POSIX-like API to expose ADS raw to user
> > > space.
> > >
> > > There is, however, an old function we still expose to user space
> > > for backward compat:
> > >
> > >   #include 
> > >
> > >   int cygwin_attach_handle_to_fd (char *name,
> > >   int fd,
> > >   HANDLE handle,
> > >   mode_t bin,
> > >   DWORD myaccess);
> > >
> > > This allows to sneak in a HANDLE into a Cygwin file descriptor
> > > representation, kind of like this:
> > >
> > >   HANDLE h;
> > >   int fd;
> > >
> > >   h = CreateFile ("foo:bar", GENERIC_READ, FILE_SHARE_VALID_FLAGS,
> > >   NULL, OPEN_EXISTING, 0, NULL);
> > >   if (h != INVALID_HANDLE_VALUE)
> > > {
> > >   fd = cygwin_attach_handle_to_fd ("foo", -1, h, 0, GENERIC_READ);
> > >   if (fd < 0)
> > > bail_out;
> > > }
> > >
> > > For the bin parameter, only 0, O_BINARY or O_TEXT are acceptable,
> > > for myaccess, only GENERIC_READ and/or GENERIC_WRITE are acceptable.
> >
> > Could this be abstracted into O_XATTR support, i.e. openat() file with
> > O_XATTR, and then have access to the alternate data streams in a
> > (virtual) subdir?
>
> I'm not too hot on adding more open(2) flags, the reason being,
> that we have room left for only 7 more flags in the 32 bit mode.
> Nobody knows what comes along officially in future.

Right, but Solaris, Illumos, and Opengroup draft already have O_XATTR,
so this is IMO OK.

Also, it would provide a good abstraction for alternate data stream
support, which is compatible with Windows, OSX, Solaris, Illumos, and
NTFS, ZFS, SMB, NFSv4.

>
> Apart from that, this sounds like a nice idea for Cygwin 3.6,
> provided somebody implements it, https://cygwin.com/acronyms/#SHTDI
>
> Assuming we can live without actually having a subdir and just
> allowing to open and create a file with the O_XATTR flag, it might be
> pretty simple to implement.  The path handling code would just have to
> drop the colon from the list of characters converted to the private-use
> Unicode area.
>
> Implementing the subdir is a bit more complicated, especially when
> taking opendir/readdir of that virtual subdir into account, but it
> would certainly be doable.

How do other OSes implement the O_XATTR subdir?

Thanks,
Martin

-- 
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: where is parted?

2024-01-11 Thread Christian Franke via Cygwin 

matth...@gmx.li wrote:

fdisk reports the same partition type as sfdisk. It report "Microsoft basic 
data" for NTFS as well
as for FAT32 partitions.


That is as expected and differs from MBR disks. The same GPT partition 
GUID is used for NTFS and the various FAT filesystem types.

https://en.wikipedia.org/wiki/Microsoft_basic_data_partition


--
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: where is parted?

2024-01-11 Thread gs-cygwin.com--- via Cygwin 
On Thu, Jan 11, 2024 at 12:38:29PM +0100, Matthias--- via Cygwin wrote:
> fdisk reports the same partition type as sfdisk. It report "Microsoft basic 
> data" for NTFS as well
> as for FAT32 partitions.
> 
> Am Donnerstag, dem 11.01.2024 um 11:56 +0100 schrieb Christian Franke via 
> Cygwin:
> > Matthias--- via Cygwin wrote:
> > > I'm using sfdisk for analysing partitions on msdos partition tables. 
> > > Unfortunately it don't
> > > support
> > > GPT tables.
> > > Is there another tool, like parted, what can be used?
> >
> > /sbin/fdisk from package util-linux-2.33.1-2 supports GPT.
> >
> > --
> > Regards,
> > Christian

(Aside: Matthias, this list prefers bottom posting.
Please post at the bottom of responses.)

My go-to is gparted, though it runs on Linux.

You can boot a "live" distro on a USB stick to manipulate partitions.
https://gparted.org/download.php

gparted doc also provides:
How-to Fix Invalid MSDOS Partition Tables
https://gparted.org/h2-fix-msdos-pt.php

Cheers, Glenn

-- 
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: where is parted?

2024-01-11 Thread Matthias--- via Cygwin 
fdisk reports the same partition type as sfdisk. It report "Microsoft basic 
data" for NTFS as well
as for FAT32 partitions.

Am Donnerstag, dem 11.01.2024 um 11:56 +0100 schrieb Christian Franke via 
Cygwin:
> Matthias--- via Cygwin wrote:
> > I'm using sfdisk for analysing partitions on msdos partition tables. 
> > Unfortunately it don't
> > support
> > GPT tables.
> > Is there another tool, like parted, what can be used?
>
> /sbin/fdisk from package util-linux-2.33.1-2 supports GPT.
>
> --
> 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: where is parted?

2024-01-11 Thread Christian Franke via Cygwin 

Matthias--- via Cygwin wrote:

I'm using sfdisk for analysing partitions on msdos partition tables. 
Unfortunately it don't support
GPT tables.
Is there another tool, like parted, what can be used?


/sbin/fdisk from package util-linux-2.33.1-2 supports GPT.

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

where is parted?

2024-01-11 Thread Matthias--- via Cygwin 
Dear all,

I'm using sfdisk for analysing partitions on msdos partition tables. 
Unfortunately it don't support
GPT tables.
Is there another tool, like parted, what can be used?

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

Re: [PATCH 1/2] Cygwin: Make 'ulimit -c' control writing a coredump

2024-01-11 Thread Corinna Vinschen 
On Jan 10 17:38, Jon Turney wrote:
> On 10/01/2024 15:30, Corinna Vinschen wrote:
> > On Jan 10 13:57, Jon Turney wrote:
> [...]
> > > 
> > > Also: Fix the (deprecated) cygwin_dumpstack() function so it will now
> > > write a .stackdump file, even when ulimit -c is zero. (Note that
> > > cygwin_dumpstack() is still idempotent, which is perhaps odd)
> > 
> > Given it's deprecated and not exposed in the headers, and given
> > we only still need the symbol for backward compat, how about making
> > this function a no-op instead?
> 
> We still need the function internally to write stackdumps.

Oh, right, I missed the usage in api_fatal.  I was only talking
about the exported function, or rather, the fact that it's exported.
We could split it in internal and external function and...

> I know it's use has long been discouraged, but doing a GitHub code search
> does find some uses of it.  What is the suggested replacement?

...doing nothing in the exported function was the idea.  There appear to
be a handful of projects on github though, which call it.  Not sure it's
the right thing to do, though.  External code should better raise a
signal in this case.

However, if we take it as given, and if external code calls
cygwin_stackdump, do we really want it to create a stackdump, or
shouldn't the behaviour be the same as if a core-creating signal has
been raised?  See below.

> (I'm also wondering if the idempotency is in the wrong place.  Is it
> possible for signal_exit() get called by multiple threads?  In which case it
> probably needs to do something sane in that case)

signal_exit is only called from sigpacket::process, and this method
in turn is only called from the wait_sig function, so it's only
called from the signal thread.

I just wonder if we really want to create a stackdump unconditionally
at all, after introducing corefile support and handling ulimit the
way you do it.

I.e., we have (basically) three situations:

- A core-creating signal has been raised
- api_fatal calls cygwin_stackdump
- External code calls cygwin_stackdump

Wouldn't it make sense to handle them equally, depending on
the ulimit settings?

> > Can't this be done by adding the max size as parameter to dumper?
> > 
> 
> Maybe. That would make forward/backwards compatibility problems when mixing
> dumper and cygwin versions.

How's that supposed to happen?  dumper is part of the Cygwin package,
so, together with using the right absolute path, there's no way to
use the wrong dumper version.  If so, it's certainly an SEP.

> I don't think we can control the size of the file as we write it, we'd need
> to check afterwards if it was too big, and then remove/truncate.
> 
> And we need to do the same action for stackdumps, so I think it makes more
> sense to do that checking in the DLL.

I see.  It's a bit unfortunate though, if dumper tries to create
a 2 Gigs file which is later truncated, if we're low on disk space.
But yeah, disk space isn't much of a problem these days, I guess...

> [...]
> > > diff --git a/winsup/cygwin/environ.cc b/winsup/cygwin/environ.cc
> > > index 008854a07..dca5c5db0 100644
> > > --- a/winsup/cygwin/environ.cc
> > > +++ b/winsup/cygwin/environ.cc
> > > @@ -832,6 +832,7 @@ environ_init (char **envp, int envc)
> > >   out:
> > > findenv_func = (char * (*)(const char*, int*)) my_findenv;
> > > environ = envp;
> > > +  dumper_init ();
> > 
> > Sorry, but I don't quite understand why dumper_init is called so early
> > and unconditionally.  Why not create the command on the fly?
> 
> For the same reason we create the error_start debugger command at process
> initialisation.
> 
> If I had to guess, that's because calling malloc() when we're in the middle
> of crashing may not be very reliable.
> 
> (of course, we go on to ruin this attention to detail by calling
> small_printf to append the Windows PID during exec_prepared_command(), even
> though we also knew that at process startup)
> 
> [...]
> > > -extern "C" void
> > > -error_start_init (const char *buf)
> > > +static void
> > > +command_prep (const char *buf, PWCHAR *command)
> > >   {
> > > -  if (!buf || !*buf)
> > > -return;
> > > -  if (!debugger_command &&
> > > -  !(debugger_command = (PWCHAR) malloc ((2 * NT_MAX_PATH + 20)
> > > - * sizeof (WCHAR
> > > +  if (!*command &&
> > > +  !(*command = (PWCHAR) malloc ((2 * NT_MAX_PATH + 20)
> > > + * sizeof (WCHAR
> > 
> > Not your fault, but the length of this string must not exceed 32767 wide
> > chars, incuding the trailing \0 per
> > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw
> > The only reason I can see for using these large arrays is to avoid
> > length checks.
> > 
> > We could get away with two static 64K pages for debugger_command and
> > dumper_command.  Or even with one if we just copy the required stuff
> > into the single

For cygwin developers

2024-01-11 Thread © Fxzx mic via Cygwin 
Hi all!
If there is a need for certain teams to complete the complex task of reviving 
WSL1, I can only think of Cygwin.
Please check here: https://github.com/trungnt2910/lxmonika/tree/master/lxmonika



From:
Fxzx mic
fxzx...@outlook.com




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