Does Windows vim have a Unix-like fmt command that can intelligently
truncate 80 character lines at the preceding space like :!fmt does?

On Sat, 12 Mar 2022 22:36:52 +0530, in alt.comp.os.windows-10 you
wrote:

> Does Windows vim have a Unix-like fmt command that can
> intelligently truncate 80 character lines at the preceding space
> like :!fmt does?

https://vi.stackexchange.com/questions/509/can-i-justify-text-in-vim

On 12-03-2022 18:28 mechanic <mechanic@example.net> wrote:

> https://vi.stackexchange.com/questions/509/can-i-justify-text-in-vim

Most of that was for linux but I tried the vim commands which didn't fail.
But they didn't work either.

This didn't fail but it didn't do anything.
:runtime macros/justify.vim
_j

This didn't fail either but it didn't do anything either.
:runtime macros/justify.vim
:set textwidth=80
:set formatoptions+=t
:nnoremap <C-j> gggqG_j
_j

What is needed is a solution that works on Windows.

On 3/12/2022 12:06 PM, mike wrote:
> Does Windows vim have a Unix-like fmt command that can intelligently
> truncate 80 character lines at the preceding space like :!fmt does?

You're holding it wrong. Try

:%!/usr/bin/fmt -w 80

The % is a shorthand for the whole file, as % is the end of the file.
Then, having given it a target to work on, call the /usr/bin/fmt of
the bash shell file tree you're running vim in.

I had to find a thread on askubuntu.com to learn that I needed %.
I was escaping to shell OK, but just sitting there like a dope,
and control-c would return me to my vim session. Once the percent
was in there, the fmt worked seamlessly.

In the following, is shown two native Ubuntu windows, before and after.
The two panes at the bottom are Windows Terminal (Powershell) of
Windows 11, with a call to bash first, to enter bash shell, then
vim sample.txt, to edit my overly-long sample file that needs formatting.
The same bash shell is in Windows 10, with the same distro (Ubuntu 20.04)
available.

[Picture] If the frame is empty, right-click and select "Reload"

https://i.postimg.cc/yx1FZ56F/vim.gif

Since there are multiple ways now of getting executables, a hint
as to where you're working would help. In my case, it is bash shell
(wsl2) without wslg (no graphics capability native yet), Ubuntu 20.04
is the release used for the vim run. Remarkably similar to the real
Ubuntu running on the screen to my left, which made the "Ubuntu-colored"
part of the picture.

Paul

On 12-03-2022 17:33 Paul <nospam@needed.invalid> wrote:

>:%!/usr/bin/fmt -w 80

C:\Windows\system32\cmd.exe /c (/usr/bin/fmt)
The system cannot find the path specified.
shell returned 1
Hit any key to close this window...

I was hoping not to have to install linux into windows.
But maybe that's the only way.
You'd think a macro would exist for Windows vim since it's a normal thing.

On Sat, 12 Mar 2022 19:33:52 -0500, Paul wrote:
> On 3/12/2022 12:06 PM, mike wrote:
> > Does Windows vim have a Unix-like fmt command that can intelligently
> > truncate 80 character lines at the preceding space like :!fmt does?
>
> You're holding it wrong. Try
>
> :%!/usr/bin/fmt -w 80

The OP complained that there was too much Linux in the reference he
found on line, so I think he wants a Windows solution and not any
variety of UNIX.

I don't know of a way in native Windows to wrap lines at or before
the 80th character. But Vim downloads for Windows are readily
available, and Vim can certainly do the job.

1. Create an auxiliary command file, called for example cmd.txt:

:set tw=80
:normal V$G
:normal gq
:wq

These four lines set wrap width to 80 characters, highlight the
entire file, wrap the highlighted part, and exit after writing the
changed file.

NOTE 1: Commands are case sensitive.

NOTE 2: Wrapping will apply to each section of text delimited by
blank lines.

2. Invoke Vim, using that command file to process the text file:

vim -c "so cmd.txt" textfilename

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

On 3/12/2022 8:18 PM, Stan Brown wrote:
> On Sat, 12 Mar 2022 19:33:52 -0500, Paul wrote:
>> On 3/12/2022 12:06 PM, mike wrote:
>>> Does Windows vim have a Unix-like fmt command that can intelligently
>>> truncate 80 character lines at the preceding space like :!fmt does?
>>
>> You're holding it wrong. Try
>>
>> :%!/usr/bin/fmt -w 80
>
> The OP complained that there was too much Linux in the reference he
> found on line, so I think he wants a Windows solution and not any
> variety of UNIX.
>
> I don't know of a way in native Windows to wrap lines at or before
> the 80th character. But Vim downloads for Windows are readily
> available, and Vim can certainly do the job.
>
> 1. Create an auxiliary command file, called for example cmd.txt:
>
> :set tw=80
> :normal V$G
> :normal gq
> :wq
>
> These four lines set wrap width to 80 characters, highlight the
> entire file, wrap the highlighted part, and exit after writing the
> changed file.
>
> NOTE 1: Commands are case sensitive.
>
> NOTE 2: Wrapping will apply to each section of text delimited by
> blank lines.
>
> 2. Invoke Vim, using that command file to process the text file:
>
> vim -c "so cmd.txt" textfilename

OK, where are you finding a vim ???

C:\Windows\System32\ ???
C:\Windows\System32\vim\ ???
C:\Program Files\Vim ???

On this copy of Windows 11 Home, there is no vim other
than the one in bash shell. Running a powershell or
a command prompt, is not digging up a positive response,
and neither is an Agent Ransack search.

I don't see anything in "Windows Features" that suggests
a vim is hiding in it.

I switched disks and checked a Win10 install. In a mozilla-build
tree and msys, I found an instance of some vim stuff. But that's an
auxiliary addition from Mozilla.

*******

Coreutils has a fmt in it. The installer will presumably attempt
to add something to %path%. I've never used "professional" installs
for those, just tossing a few bits and pieces into a work folder
when I need one. Back when Microsoft hated Linux, this is how
you got some of those functions.

http://gnuwin32.sourceforge.net/packages/coreutils.htm

Paul

On 13-03-2022 10:00 Paul <nospam@needed.invalid> wrote:

>> vim -c "so cmd.txt" textfilename
>
> OK, where are you finding a vim ???

I didn't realize Windows comes with vim/gvim but you seem to have found it
in an ancillary bash shell.

I loaded gvim from https://www.vim.org/download.php

I first blindly followed Stan's instructions which did something but not
what I wanted. (Some lines were still very long, some were wrapped at 80,
and blank lines seem to have disappeared.) I wasn't too worried about that
though as I didn't want a command line solution but an in-file !fmt result.

I ran the suggested commands inside a gvim session but they didn't wrap at
first, but since I was unfamiliar with the :normal command, I realized from
looking it up that "normal" requires additional "shift+q" & "return"
sequences (which adds a carriage return, usually signified as "^M" in
instructions).
https://vim.fandom.com/wiki/Using_normal_command_in_a_script_for_searching
https://stackoverflow.com/questions/426896/vim-ctrl-v-conflict-with-windows-paste

With the shift+q (in Linux it's control+q I think) in mind, this works well.

Inside a gvim session, set the textwidth :set tw=80
Position the cursor to where you want to begin wrapping long lines.
Wrap at the first blank behind 80 characters :normal V$G<shift+q><return>
That wraps from the cursor on down & puts the cursor at the end of the file.
This didn't do anything that I could tell :normal gq
This wrote and quit :wq

I knew the $G moved the cursor to the beginning of the last line of the
file.

But I wasn't familiar with the "V" command which is a "line Visual" mode.
https://opensource.com/article/19/2/getting-started-vim-visual-mode

I also wasn't familiar with the normal command which is "normal mode."
http://vimdoc.sourceforge.net/htmldoc/various.html#:normal

I still am not sure if the "gq" does anything but looking up ":g" tells me
that it somehow "marks every line for a pattern" but the "q" means "quit".
https://vim.fandom.com/wiki/Power_of_g

I'm not sure what ":normal gq" does, as a result of it not doing anything I
could see, but if I ignore it, the solution still works the same.

Assuming the textwidth=80 is set in the _gvimrc file, all I need to do now
is look up how to simplify (with a macro perhaps) the "V$G^M" typing steps.

Much appreciation goes out to Stan Brown for the ":normal V$G^M" sequence!

On Sun, 13 Mar 2022 00:48:18 +0530, mike wrote:

> On 12-03-2022 18:28 mechanic <mechanic@example.net> wrote:
>
>> https://vi.stackexchange.com/questions/509/can-i-justify-text-in-vim
>
> Most of that was for linux but I tried the vim commands which didn't fail.
> But they didn't work either.
>
> This didn't fail but it didn't do anything.
> :runtime macros/justify.vim
> _j
>
> This didn't fail either but it didn't do anything either.
> :runtime macros/justify.vim
> :set textwidth=80
> :set formatoptions+=t
> :nnoremap <C-j> gggqG_j
> _j
>
> What is needed is a solution that works on Windows.

Vim and gvim work perfectly well in Windows. No need to run away to
Linux. Getting the right instructions in your gvimrc file takes time
so be patient with your trials. It's a pity that 'par' never got
much drive behind it, it was a much better formatter than the 'fmt'
program in bash. With the few commands you need in your rc file
(textwidth is important) you'll be set with the right options for
your needs. The spell check is pretty good in vim too! I use vim as
the alternate editor in the emailer, and it's pretty good.

On Sun, 13 Mar 2022 11:28:38 +0530, mike wrote:

> I still am not sure if the "gq" does anything but looking up ":g" tells me
> that it somehow "marks every line for a pattern" but the "q" means "quit".
> https://vim.fandom.com/wiki/Power_of_g

gq is an operator, to be followed by a selector. I use the command
'gqap' a lot to reformat paragraphs.

http://vimdoc.sourceforge.net/htmldoc/usr_25.html

Read the section 'REFORMATTING'

On Sat, 12 Mar 2022 23:30:21 -0500, Paul wrote:
>
> On 3/12/2022 8:18 PM, Stan Brown wrote:
> > The OP complained that there was too much Linux in the reference
> > he
> > found on line, so I think he wants a Windows solution and not any
> > variety of UNIX.
> >
> > I don't know of a way in native Windows to wrap lines at or before
> > the 80th character. But Vim downloads for Windows are readily
> > available, and Vim can certainly do the job.
> >
> > 1. Create an auxiliary command file, called for example cmd.txt:
> >
> > :set tw=80
> > :normal V$G
> > :normal gq
> > :wq
> >
> > These four lines set wrap width to 80 characters, highlight the
> > entire file, wrap the highlighted part, and exit after writing the
> > changed file.
> >
> > NOTE 1: Commands are case sensitive.
> >
> > NOTE 2: Wrapping will apply to each section of text delimited by
> > blank lines.
> >
> > 2. Invoke Vim, using that command file to process the text file:
> >
> > vim -c "so cmd.txt" textfilename
>
> OK, where are you finding a vim ???

It's a third-party application, which I have used for decades and
which someone mentioned upthread. I didn't state explicitly that it
doesn't come with Windows, but I thought that was implied by "I don't
know of a way in native Windows to wrap lines at or before the 80th
character."

Vim can be downloaded from www.vim.org. It's 100% free; the author
requests that you donate to poor children in Uganda but there's no
nagging.

Vim definitely has a learning curve, but you can do about anything in
it, and one great benefit is that it's been ported to almost every OS
there is. I used to use it on VAX/VMS.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

On Sun, 13 Mar 2022 11:28:38 +0530, mike wrote:
> I first blindly followed Stan's instructions which did something but not
> what I wanted. (Some lines were still very long, some were wrapped at 80,
> and blank lines seem to have disappeared.)

Empty lines would not disappear. Lines with only blanks on them would
be part of the reflow.

I tested my script before posting, so I must have not understood what
you wanted.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

Stan Brown wrote:

> Vim definitely has a learning curve, but you can do about anything in
> it, and one great benefit is that it's been ported to almost every OS
> there is. I used to use it on VAX/VMS.

To be purposefully helpful and to advise Paul about the ubiquity of "vi",
I can emphatically second what Stan Brown said which is that many people who
worked in the Silicon Valley like I did for decades went through the phases
of AT&T Unix, Masscomp, Sun, DEC, etc., well before "Linux" became the norm.

We'd go to customer sites and then need to work on their computer as
portable computers didn't exist either - so you were at the mercy of
"whatever they had" as your text editor, such as emacs or nano.

You soon learned that "ed" (as I recall) was always there but so was "vi"
which was a hellova lot better (in most of our opinions). Sure there were
others, but "vi" was _always_ gonna be there (and in the default path).

As Stan Brown said, the learning curve is horrific, but once it's engrained
into your finger memory, you never forget it (it's like your first car).

Then Linux supplanted SunOS/Solaris and "vi" was still always there.
When we moved to Windows, the Notepad was atrocious (and probably still is).

So we simply added gVim (which is basically an almost perfect copy of vi on
Windows) where gVim has the best of both worlds in terms of GUI and
finger-control. I'm sure Stan Brown knows this, but vi was designed to be
_all_ fingers, so almost anything (if not everything) can be done with your
fingers.

The gVim GUI sucks but that doesn't matter (IMHO) since you almost never
need to use it, except maybe to position the cursor when where you want the
cursor to be is already on the screen.

In fact, Marek Novotny wrote most of my "newsreader" scripts which I'm using
to compose this message where I'm composing in gVim and sending via telnet
scripts (i.e., my "newsreader" is vi plus a bunch of telnet scripts).

The advantage of vi is that it can do anything.
The disadvantage of vi is that the learning curve is at least a month.

One _great_ thing though is if you've used vi for decades, like I have, and
like Stan Brown probably has, the GUI never changes in any way that you
care.

By way of contrast, if you used Microsoft Word 2003 and then 2007 and then
2010 and then 2016, etc., the damn GUI changes a lot.

Same stuff. Different location.
That _never_ happens with vi.

As my wife (whom I met at a startup when I moved to the Silicon Valley) used
to tell me, diamonds aren't forever, "vi is forever".

Andy Burnelli wrote:

> As Stan Brown said, the learning curve is horrific, but once it's engrained
> into your finger memory, you never forget it (it's like your first car).

In post processing that comment I want to stress that it's like learning to
drive your first car assuming that first car was a manual transmission.

The learning curve (as most of us were somewhere around 13 or 14 when we
learned to drive) is something that never leaves you as most of you must
know who drove sticks in those days.

You never forget how to drive a stick (nor how to ride a motorcycle).

It never changes no matter what vehicle you are in, which is why Stan Browne
mentioned that it's the one text editor that you can always count on as the
location of the commands never change given they're all on the keyboard.

Most of us do keep a cheat sheet in Windows which I recommend setting up.
Run > vi
Where that brings up your cheat sheet, oh, say, in
c:\data\docs\hints\vi.txt
And where there's a one-time setup for Run commands in the registry
Computer\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\
vi.exe === c:\data\docs\hints\vi.txt

An example of what you might have in your vi cheat sheet could be
%s/^/\=printf('%-4d', line('.')) => insert line numbers
:g/^\s*$/d => remove blank lines
:g/^$/d => delete empty lines
:%s/\s\+$//e => eliminate duplicate blank lines
:v/\S/,/\S/-j => join consequitive lines not between blank lines
:g/^[ \t\u3000]*$/d => remmove empty lines & lines with space, tab or ideographs
etc.
--
Working alongide intelligent helpful people, we can solve most problems.

On Sunday, March 13, 2022 at 3:50:30 AM, mechanic wrote:

> Vim and gvim work perfectly well in Windows.

Would the MKS Toolkit "fmt" command work on Windows?
https://www.mkssoftware.com/docs/man1/fmt.1.asp

On Fri, 18 Mar 2022 08:23:38 -0700, in alt.comp.os.windows-10 you
wrote:

> On Sunday, March 13, 2022 at 3:50:30 AM, mechanic wrote:
>
>> Vim and gvim work perfectly well in Windows.
>
> Would the MKS Toolkit "fmt" command work on Windows?
> https://www.mkssoftware.com/docs/man1/fmt.1.asp

'fmt' -> not an editor command

You can run external Linux commands but in windows (unless you have
cygwin or something like that) that 'fmt' command won't be
recognised.

On Fri, 18 Mar 2022 18:44:49 +0000, mechanic wrote:

>> Would the MKS Toolkit "fmt" command work on Windows?
>> https://www.mkssoftware.com/docs/man1/fmt.1.asp
>
> 'fmt' -> not an editor command
>
> You can run external Linux commands but in windows (unless you have
> cygwin or something like that) that 'fmt' command won't be
> recognised.

Try this inside gvim and you'll see how the editor calls external commands.
:!sort u
:%sort

One calls the external sort command (found in the path).
The other calls the internal sort command (which has different options).

It would act the same with the fmt command if it's in the user's PATH.

On Fri, 18 Mar 2022 18:44:49 +0000, mechanic wrote:
> You can run external Linux commands but in windows (unless you have
> cygwin or something like that) that 'fmt' command won't be
> recognised.
>

What about WSL? If we install WSL, do we simply get the shell, or do
we get commands like fmt?

<https://docs.microsoft.com/en-us/windows/wsl/about>
says "The Windows Subsystem for Linux lets developers run a GNU/Linux
environment -- including most command-line tools, utilities, and
applications -- directly on Windows. ... Run Bash shell scripts and
GNU/Linux command-line applications including: vim, emacs, tmux. ..."

That certainly sounds like you'd get fmt, assuming fmt is a standard
Linux command-line utility. (My Linux knowledge isn't deep enough to
know whether it is or it isn't.)

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

On 3/18/2022 4:03 PM, Stan Brown wrote:
> On Fri, 18 Mar 2022 18:44:49 +0000, mechanic wrote:
>> You can run external Linux commands but in windows (unless you have
>> cygwin or something like that) that 'fmt' command won't be
>> recognised.
>>
>
> What about WSL? If we install WSL, do we simply get the shell, or do
> we get commands like fmt?
>
> <https://docs.microsoft.com/en-us/windows/wsl/about>
> says "The Windows Subsystem for Linux lets developers run a GNU/Linux
> environment -- including most command-line tools, utilities, and
> applications -- directly on Windows. ... Run Bash shell scripts and
> GNU/Linux command-line applications including: vim, emacs, tmux. ..."
>
> That certainly sounds like you'd get fmt, assuming fmt is a standard
> Linux command-line utility. (My Linux knowledge isn't deep enough to
> know whether it is or it isn't.)

In the Bash shell on Windows (WSL), this is a user directory

/mnt/c/users/username/Downloads

and this is a location of a tool and its friend.

/usr/bin/fmt
/usr/bin/vim

The /usr/bin is inside this container.

C:\Users\username\AppData\Local\Packages\
CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState\

Name: ext4.vhdx
Size: 2,185,232,384 bytes (2084 MiB)

The size grows as you add Ubuntu packages to it with

sudo apt install vim

The .vhdx file can't be opened with 7ZIP, whereas 7ZIP opens .vhd files just
fine and .vhdx is more of a orphan (Hyper-V) format. I don't know if I have
a third-party tool to convert a .vhdx to something else.

But ext4.vhdx is in principle where /usr/bin/vim or /usr/bin/vim.basic is located.

Paul

Stan Brown <the_stan_brown@fastmail.fm> wrote:
> On Fri, 18 Mar 2022 18:44:49 +0000, mechanic wrote:
>> You can run external Linux commands but in windows (unless you have
>> cygwin or something like that) that 'fmt' command won't be
>> recognised.
>>
>
> What about WSL? If we install WSL, do we simply get the shell, or do
> we get commands like fmt?

Once WSL is enabled you can install a complète linux distribution - Ubuntu
or SUSE - and so you can have whatever linux tools you want.

However, it's massive overkill for your needs. If you can't get vim to work
as you like just use Notepad++ instead.

On Sat, 19 Mar 2022 09:37:18 -0000 (UTC), Chris wrote:

> Once WSL is enabled you can install a compl�te linux distribution - Ubuntu
> or SUSE - and so you can have whatever linux tools you want.
>
> However, it's massive overkill for your needs. If you can't get vim to work
> as you like just use Notepad++ instead.

Notepad++ solves nothing unless you already have a fmt.exe executable.
Even then, the op needs to call the fmt.exe command from within Notepad++.

The Windows port of the GNU CoreUtils has a fmt.exe executable for example.
http://gnuwin32.sourceforge.net/packages/coreutils.htm

that fmt.exe port seems to have the options for what the op is asking for.
https://www.pconlife.com/viewfileinfo/fmt-exe/

But how does the op call that fmt.exe command from within Notepad++?

On Fri, 18 Mar 2022 23:48:20 -0400, Paul wrote:

> In the Bash shell on Windows (WSL), this is a user directory
>
> /mnt/c/users/username/Downloads
>
> and this is a location of a tool and its friend.
>
> /usr/bin/fmt
> /usr/bin/vim

All that is needed is any fmt.exe executable which is ported to Windows.

A search found fmt.exe in the Windows Tiny Unix Tools for Windows site.
https://tinyapps.org/blog/201606040700_tiny_unix_tools_windows.html

That's inside something called Git For Windows which I've never heard of.
https://gitforwindows.org/

What do you think of this Git for Windows unix environment?

It's also in Unix Tools For Windows but that's only in an archive.
https://web.archive.org/web/20040803020450/http://thinstall.com/help/index.html?unixtooldemo.htm

Ever use that?

Jerry <Jerry@JerryThinks.com> wrote:
> On Sat, 19 Mar 2022 09:37:18 -0000 (UTC), Chris wrote:
>
>> Once WSL is enabled you can install a complète linux distribution - Ubuntu
>> or SUSE - and so you can have whatever linux tools you want.
>>
>> However, it's massive overkill for your needs. If you can't get vim to work
>> as you like just use Notepad++ instead.
>
> Notepad++ solves nothing unless you already have a fmt.exe executable.
> Even then, the op needs to call the fmt.exe command from within Notepad++.
>
> The Windows port of the GNU CoreUtils has a fmt.exe executable for example.
> http://gnuwin32.sourceforge.net/packages/coreutils.htm
>
> that fmt.exe port seems to have the options for what the op is asking for.
> https://www.pconlife.com/viewfileinfo/fmt-exe/
>
> But how does the op call that fmt.exe command from within Notepad++?

I wouldn't be surprised if there's an equivalent functionality or plugin
available.

Chris <ithinkiam@gmail.com> wrote:
> Jerry <Jerry@JerryThinks.com> wrote:
>> On Sat, 19 Mar 2022 09:37:18 -0000 (UTC), Chris wrote:
>>
>>> Once WSL is enabled you can install a complète linux distribution - Ubuntu
>>> or SUSE - and so you can have whatever linux tools you want.
>>>
>>> However, it's massive overkill for your needs. If you can't get vim to work
>>> as you like just use Notepad++ instead.
>>
>> Notepad++ solves nothing unless you already have a fmt.exe executable.
>> Even then, the op needs to call the fmt.exe command from within Notepad++.
>>
>> The Windows port of the GNU CoreUtils has a fmt.exe executable for example.
>> http://gnuwin32.sourceforge.net/packages/coreutils.htm
>>
>> that fmt.exe port seems to have the options for what the op is asking for.
>> https://www.pconlife.com/viewfileinfo/fmt-exe/
>>
>> But how does the op call that fmt.exe command from within Notepad++?
>
> I wouldn't be surprised if there's an equivalent functionality or plugin
> available.

Actually looks like sublime text can do justification really well.
https://packagecontrol.io/packages/Justify

On 3/19/2022 8:22 AM, Jerry wrote:
> On Fri, 18 Mar 2022 23:48:20 -0400, Paul wrote:
>
>> In the Bash shell on Windows (WSL), this is a user directory
>>
>>     /mnt/c/users/username/Downloads
>>
>> and this is a location of a tool and its friend.
>>
>>     /usr/bin/fmt
>>     /usr/bin/vim
>
> All that is needed is any fmt.exe executable which is ported to Windows.
>
> A search found fmt.exe in the Windows Tiny Unix Tools for Windows site.
> https://tinyapps.org/blog/201606040700_tiny_unix_tools_windows.html
>
> That's inside something called Git For Windows which I've never heard of.
> https://gitforwindows.org/
>
> What do you think of this Git for Windows unix environment?
>
> It's also in Unix Tools For Windows but that's only in an archive.
> https://web.archive.org/web/20040803020450/http://thinstall.com/help/index.html?unixtooldemo.htm
>
> Ever use that?

I just use gunwin32 (ten years old).
Some of the packages contain sets of executables.

http://gnuwin32.sourceforge.net/packages/coreutils.htm

Others can be more selective.

http://gnuwin32.sourceforge.net/packages.html

There's also Cygwin, which I'm told by others here is
still going. Once you pull something in from the Cygwin
tree, you can keep just the EXE and a couple of DLLs and
use the stuff in a portable manner. So in some ways,
a similar set of support issues to gnuwin32.

The namespaces can be slightly different. Cygwin might
use /dev/sda as an identifier for the first disk drive.
Gnuwin32 might use identifiers similar to how dd.exe
from Chrysocome uses them.

There can also be line ending differences. The Gawk in
WSL uses Linux line endings, and needs a two line Begin
clause added to source scripts. The GNUwin32 Gawk 3 uses
Windows line endings making it "more" native.

The differences can be very subtle (and annoying, if you
let such things annoy you).

The netpbm in the GNUWin32 collection, might be a more
complete set than the netpbm in WSL. I installed netpbm
the other day in WSL and discovered it's no longer
a complete orthogonal set (if there is atob there is btoa
as well kind of thing). Netpbm was kinda over the top
when that person was working on it. Cutting it down to
the subset in WSL isn't really doing anyone any favors.
Sure, it's more secure I suppose, but hardly "helpful".

There are lots of old codes and libraries which were
never "hardened" and had exploitable stuff removed
from them. You could download a JPeg with a corrupt
header and tip over the machine, with some of the
uncorrected libraries. There might be a danger of that
with the ten year old GNUWin32 for that matter.
It's quite possible Windows Defender could be scanning
your JPeg and checking for that, before you get to
play with it.

Not everything is a box of chocolates out there :-)
You might have to make tradeoffs between completeness
and security when evaluating sources of ports. Maybe
something you test for the first time, isn't blatantly
filled with malware, but it might have defects you don't
know about, that are already listed somewhere in a CVE.
I'm quite sure my small collection here is filled
with issues like that.

Paul