From Newsgroup: alt.msdos.batch

PSA: How to add WSL grep to the Windows command-line PATH

This is an Android:Windows cross-platform problem that I run into every
day because most adb examples we find on the net use grep (not findstr).

It's a PITA to constantly convert adb examples using grep to findstr.

So this approach below is what I just decided to finally do after getting
tired of converting adb|grep examples found on the net to findstr syntax.

I recognize there are many ways to add "grep" to the Windows path.
But, since I already had WSL installed for other reasons, it bothered me
that I couldn't just call the Ubuntu grep from the Windows command line.

What good is WSL if you can't use it when you need it?

Hence, I came up with this method of calling the WSL grep from Windows.

It may be one of the simplest methods to run any WSL Linux tool directly
from the Windows CMD (or powershell) using a simple wrapper script.

But I've only tested it just now with just grep (not sed, awk, ls, etc.).

Unfortunately, WSL Linux binaries aren't normal Windows executables.

Hence, just adding the WSL Linux binary to Windows PATH
won't make CMD able to execute it. That would be too easy.

But this method just now worked perfectly, for me, on Windows 10.

Here's the sample x-platform adb:android:windows command we want to run.

adb shell pm list packages | grep -i gsf

'grep' is not recognized as an internal or external command,
operable program or batch file.

Of course, we've all used CYGWIN and other UNIX binaries in the
past, but I already have WSL so why not use the grep it came with.

First, let's prove WSL 1 is installed and working.

wsl --list --verbose

NAME STATE VERSION
* Ubuntu Stopped 1

And, let's prove WSL has a working grep too.

wsl grep --version

grep (GNU grep) 3.11

Since it's there, let's add a "grep.cmd" to a file in our path:

gvim C:\path-to\grep.cmd

@wsl grep %*

Then test from anywhere on the command line:

grep --version

grep (GNU grep) 3.11

Let's get back to what we were doing, which was testing GSF:

adb shell pm list packages | grep -i gsf

package:com.google.android.gsf

Voila!

I haven't tested any of the other WSL Linux commands, but from this simple
grep test, I would hope that the others (sed, awk, etc.) should work too.

Do they?
--
On Usenet, kind hearted people try to help each other all day every day.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia wrote:

PSA: How to add WSL grep to the Windows command-line PATH

This is an Android:Windows cross-platform problem that I run into every
day because most adb examples we find on the net use grep (not findstr).

It's a PITA to constantly convert adb examples using grep to findstr.

So this approach below is what I just decided to finally do after getting tired of converting adb|grep examples found on the net to findstr syntax.

I recognize there are many ways to add "grep" to the Windows path.
But, since I already had WSL installed for other reasons, it bothered me
that I couldn't just call the Ubuntu grep from the Windows command line.

What good is WSL if you can't use it when you need it?

Hence, I came up with this method of calling the WSL grep from Windows.

It may be one of the simplest methods to run any WSL Linux tool directly
from the Windows CMD (or powershell) using a simple wrapper script.

But I've only tested it just now with just grep (not sed, awk, ls, etc.).

Unfortunately, WSL Linux binaries aren't normal Windows executables.

Hence, just adding the WSL Linux binary to Windows PATH
won't make CMD able to execute it. That would be too easy.

But this method just now worked perfectly, for me, on Windows 10.

Here's the sample x-platform adb:android:windows command we want to run.

adb shell pm list packages | grep -i gsf

'grep' is not recognized as an internal or external command,
operable program or batch file.

Of course, we've all used CYGWIN and other UNIX binaries in the
past, but I already have WSL so why not use the grep it came with.

First, let's prove WSL 1 is installed and working.

wsl --list --verbose

NAME STATE VERSION
* Ubuntu Stopped 1

And, let's prove WSL has a working grep too.

wsl grep --version

grep (GNU grep) 3.11

Since it's there, let's add a "grep.cmd" to a file in our path:

gvim C:\path-to\grep.cmd

@wsl grep %*

Then test from anywhere on the command line:

grep --version

grep (GNU grep) 3.11

Let's get back to what we were doing, which was testing GSF:

adb shell pm list packages | grep -i gsf

package:com.google.android.gsf

Voila!

I haven't tested any of the other WSL Linux commands, but from this simple grep test, I would hope that the others (sed, awk, etc.) should work too.

Do they?

Since this simple method should work for many common Linux commands...

gvim C:\path-to\sed.cmd

@wsl sed %*

where sed

C:\path-to\sed.cmd

adb shell dumpsys battery | sed "s/ */ /g"

Current Battery Service state:
AC powered: false
USB powered: true
Wireless powered: false
Charge counter: 2916540
...

I wrote up this wsl2cli batch script so everyone can benefit more easily.
I haven't actually tested whether the commands work, but they should.

Shouldn't they?

:: ------------------------------------------------------------------------
:: wsl2cli.bat
:: Bridge common WSL Linux utilities into Windows CMD/PowerShell by
:: generating wrapper scripts in Windows that call existing WSL binaries
:: ------------------------------------------------------------------------
:: v1p8 20260826 Added keyword support (exit, quit, q) for graceful exit
:: v1p7 20260826 Switched echo. to echo: to prevent command interpreter quirks
:: v1p6 20260826 Commented out debug lines for clean production output
:: v1p5 20260826 Added ignore of empty-path tokens from trailing semicolons
:: v1p4 20260826 Added debug tracking lines inside the PATH parsing loop
:: v1p3 20260826 Fixed path evaluation bug by quoting paths in the loop
:: v1p2 20260826 Output the current PATH filespecs for easier selection
:: v1p1 20260826 Added ability to put cmd files where desired by number
:: v1p0 20260826 Make Linux commands that work in CMD using WSL calls
:: ------------------------------------------------------------------------
@echo off
setlocal EnableDelayedExpansion

echo:
echo WSL-to-CMD Wrapper Generator
echo Inspecting the Windows PATH environment variable...
echo Select the destination folder where the scripts should be placed:
echo:

:: [DEBUG] echo Entering PATH parsing loop...
set "count=0"
for %%p in ("%PATH:;=" "%") do (
call :processpath %%p
)
:: [DEBUG] echo Loop complete. Total items found: %count%
goto :postloop

:processpath
if "%~1"=="" exit /b
set /a count+=1
set "cleanPath=%~1"
:: [DEBUG] echo count=%count% ^| raw=%1 ^| clean=%cleanPath%
set "pathItem[%count%]=%cleanPath%"
echo (%count%) "%cleanPath%"
exit /b

:postloop
set /a customOpt=count+1
set /a exitOpt=count+2

echo (%customOpt%) Enter a custom path manually
echo (%exitOpt%) Exit / Abort
echo:

set /p "choice=Enter choice (1-%exitOpt%): "

:: Handle graceful exit by number or text keyword
if "%choice%"=="%exitOpt%" goto :gracefulExit
if /i "%choice%"=="exit" goto :gracefulExit
if /i "%choice%"=="quit" goto :gracefulExit
if /i "%choice%"=="q" goto :gracefulExit
goto :checkCustom

:gracefulExit
echo Exiting. No changes made.
goto :end

:checkCustom
:: Handle custom path
if "%choice%"=="%customOpt%" (
set /p "targetDir=Enter full target path (e.g., C:\bin): "
goto :process
)

:: Handle PATH selection
set "targetDir="
for /l %%i in (1, 1, %count%) do (
if "%choice%"=="%%i" set "targetDir=!pathItem[%%i]!"
)

:process
:: Validate final target directory
if not defined targetDir (
echo [Error] Invalid selection. Aborting.
goto :end
)

:: Create directory if it doesn't exist yet
if not exist "%targetDir%" (
echo Directory doesn't exist. Creating it now...
mkdir "%targetDir%"
)

echo:
echo Generating WSL wrapper scripts into:
echo -> %targetDir%
echo:

:: Define a list of core Linux commands to wrap for the Windows CLI
set "cmds=grep sed awk cut sort uniq wc tr head tail cat less more tee ls cp mv rm touch mkdir find xargs basename dirname diff comm paste join"

:: Create the wrapper
for %%c in (%cmds%) do (
echo Creating %%c.cmd
echo @wsl %%c %%* > "%targetDir%\%%c.cmd"
)

echo:
echo All wrapper scripts created successfully!
echo Since the target directory is already in the PATH, the commands can be used immediately.
echo:

:end
pause
:: end of wsl2cli.bat
--
On Usenet, some people are kind, helpful and they're knowledgeable too!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Thu, 27 Aug 2026 00:05:41 -0600, Maria Sophia wrote:

Since this simple method should work for many common Linux
commands...

How many of these do you have to write before it becomes simpler just
to run a Linux system?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence,

Since this simple method should work for many common Linux
commands...

How many of these do you have to write before it becomes simpler just
to run a Linux system?

Besides that he just ignores that for his method to work we first need to install gvim ?...

The OP is *very good* at finding "solutions", but rather bad at checking if
it will work anywhere outside his own "it works here" situation (read:
seldom any error-checking etc).

Ofcourse, on Windows the batch-interpreter also supports equates like that - iow, no need for gvim. :-)

As for the value of his PSA ? Next-to-none. A quick "how to run wsl grep from the commandline" websearch turned up this (second result) :

https://www.commandlinewizardry.com/post/running-linux-commands-within-windows-using-wsl

, which pretty-much states the obvious : just use "wsl grep"(.cmd) instead
of just "grep"(.cmd)


Ofcourse, a bit of editing the registry would work as well (catching the ".cmd" extension like any other "needs to be run by" extensions) , without
the need to write an equate for each of those WSL commands.

Oh well.

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Wed, 8/26/2026 10:08 PM, Maria Sophia wrote:

PSA: How to add WSL grep to the Windows command-line PATH

This is an Android:Windows cross-platform problem that I run into every
day because most adb examples we find on the net use grep (not findstr).

It's a PITA to constantly convert adb examples using grep to findstr.

So this approach below is what I just decided to finally do after getting tired of converting adb|grep examples found on the net to findstr syntax.

I recognize there are many ways to add "grep" to the Windows path.
But, since I already had WSL installed for other reasons, it bothered me
that I couldn't just call the Ubuntu grep from the Windows command line.

What good is WSL if you can't use it when you need it?

Hence, I came up with this method of calling the WSL grep from Windows.

It may be one of the simplest methods to run any WSL Linux tool directly
from the Windows CMD (or powershell) using a simple wrapper script.

But I've only tested it just now with just grep (not sed, awk, ls, etc.).

Unfortunately, WSL Linux binaries aren't normal Windows executables.

Hence, just adding the WSL Linux binary to Windows PATH
won't make CMD able to execute it. That would be too easy.

But this method just now worked perfectly, for me, on Windows 10.

Here's the sample x-platform adb:android:windows command we want to run.

adb shell pm list packages | grep -i gsf

'grep' is not recognized as an internal or external command,
operable program or batch file.

Of course, we've all used CYGWIN and other UNIX binaries in the
past, but I already have WSL so why not use the grep it came with.

First, let's prove WSL 1 is installed and working.

wsl --list --verbose

NAME STATE VERSION
* Ubuntu Stopped 1

And, let's prove WSL has a working grep too.

wsl grep --version

grep (GNU grep) 3.11

Since it's there, let's add a "grep.cmd" to a file in our path:

gvim C:\path-to\grep.cmd

@wsl grep %*

Then test from anywhere on the command line:

grep --version

grep (GNU grep) 3.11

Let's get back to what we were doing, which was testing GSF:

adb shell pm list packages | grep -i gsf

package:com.google.android.gsf

Voila!

I haven't tested any of the other WSL Linux commands, but from this simple grep test, I would hope that the others (sed, awk, etc.) should work too.

Do they?

Isn't there some Rust version of GREP ? That's assuming the package
is available right now.

https://learn.microsoft.com/en-us/windows/core-utils/overview

Of all the various ways to do that, some tools have line ending problems,
and then a "native" routine becomes a better choice.

How that starts out (apparently), is it sniffs $0 when you run it
(its own filename). If it finds "grep.exe" then it knows you want grep.
If the filename was "sed.exe", it knows you want SED. By using hardlinks,
you can have executables with the "right names" for the job, and
then the storage space for the executable is one set of clusters. I have
one program I wrote for myself that works like that. The filename
can be "encode.exe" or "decode.exe" and that decides the function.

Hopefully, for anything line-ending-sensitive, that program will
do it the Windows way.

When I compared the gnuwin32 "gawk" to the WSL2 "gawk",
the gnuwin32 one was Windows endings, the WSL2 one was Linux endings.
When writing scripts in that language, a couple lines must be
added to the BEGIN preamble, to compensate for that.

By running in the Windows environment, you have all your "visible" RAM
to use. That makes scoping out limitations for a run, a little bit easier.
It looks like my WSL2 right now, is using half of system memory,
and the swap file is 25% of that number.

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Thu, 27 Aug 2026 00:05:41 -0600, Maria Sophia wrote:

Since this simple method should work for many common Linux
commands...

How many of these do you have to write before it becomes simpler just
to run a Linux system?

And make sure that you can no longer run any of your Windows software? [1]

But to the point: Don't confuse "Arlen"'s convoluted methods with what
most others are doing.

There are many solutions for running Unix/UNIX/GNU commands on
Windows. Paul mentions one. I'm using another since well over two
decades (see User-Agent: header) and have been using similar solutions
since the early MS-DOS days. This is a total non-'problem'.

[1] This is one of them rhetorical thingies.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Paul wrote:

Isn't there some Rust version of GREP ? That's assuming the package
is available right now.

https://learn.microsoft.com/en-us/windows/core-utils/overview

Of all the various ways to do that, some tools have line ending problems,
and then a "native" routine becomes a better choice.

How that starts out (apparently), is it sniffs $0 when you run it
(its own filename). If it finds "grep.exe" then it knows you want grep.
If the filename was "sed.exe", it knows you want SED. By using hardlinks,
you can have executables with the "right names" for the job, and
then the storage space for the executable is one set of clusters. I have
one program I wrote for myself that works like that. The filename
can be "encode.exe" or "decode.exe" and that decides the function.

Hopefully, for anything line-ending-sensitive, that program will
do it the Windows way.

When I compared the gnuwin32 "gawk" to the WSL2 "gawk",
the gnuwin32 one was Windows endings, the WSL2 one was Linux endings.
When writing scripts in that language, a couple lines must be
added to the BEGIN preamble, to compensate for that.

By running in the Windows environment, you have all your "visible" RAM
to use. That makes scoping out limitations for a run, a little bit easier.
It looks like my WSL2 right now, is using half of system memory,
and the swap file is 25% of that number.

Hi Paul,

Thanks for bringing up RUST which, um, I had not heard of prior.
<https://daily.dev/posts/microsoft-ships-native-linux-coreutils-for-windows-built-on-rust-ggfo0izh5>

The problem for me is most of the suggested adb commands I find on the net tend to use Linux commands to post process raw output, usually in a pipe.
adb shell top -b -n 1 | head -n 25
adb shell pm list packages -3 | cut -d: -f2

adb shell df -h | awk 'NR==1 || /\/data$/ {print $1, $5, $6}'

adb shell dumpsys battery | grep -E 'status|health|temperature|voltage'
etc.

We could run those Linux commands on the Android device, but it's a PITA.
adb shell 'dumpsys battery | grep level'

Looking up RUST, so that we all benefit, apparently Microsoft released Coreutils for Windows containing a set of Unix-style command-line tools
built on the open-source uutils Rust project but not 'grep' or 'find'.
*Microsoft Coreutils for Windows: native Linux command-line tools*
<https://4sysops.com/archives/microsoft-coreutils-for-windows-native-linux-command-line-tools/>

Apparently these core Linux tools are installed on Windows using winget:

winget install Microsoft.Coreutils

Found Coreutils for Windows [Microsoft.Coreutils] Version 2026.6.16
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to,
third-party packages.
Downloading
https://github.com/microsoft/coreutils/releases/download/v2026.6.16/coreutils-2026.6.16-x64.exe
100% 4.87 MB / 4.87 MB
Successfully verified installer hash
Starting package install...
The installer will request to run as administrator. Expect a prompt.
Successfully installed

Then we need to add coreutils to the Windows path

setx PATH "%PATH%;C:\Program Files\coreutils"

SUCCESS: Specified value was saved.

According to the documents above, these apparently work well:
cat, cp, ls, mv, rm, pwd, sleep, hostname
These only partially work according to the documents:
date, echo, mkdir, rmdir, find
These apparently don't come with the core utils package:
dir, more, expand, kill, chmod, chown, chroot, nuhup, tty, who, timeout,
paste, expand, whoami

I just realized that Microsoft's Coreutils package doesn't give us
grep, sed, cut or awk, so we still need additional Linux-like packages.

Drat.
Nonetheless, I just installed the coreutils, but I haven't tested it yet.
--
The great thing about Usenet is people work together to help all learn.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence D'Oliveiro wrote:

On Thu, 27 Aug 2026 00:05:41 -0600, Maria Sophia wrote:

Since this simple method should work for many common Linux
commands...

How many of these do you have to write before it becomes simpler just
to run a Linux system?

Hi Lawrence,

Rest assured I've used every operating system out there since the 1960s',
& I have "been there, done that", with dual-boot Linux/Windows long ago.

The record shows I've solved all sorts of cross-platform problems with a dual-boot Ubuntu (where, for example, it reads iOS files better'n Windows).

But asking "why not use Linux" is absolutely the wrong question to ask.

The right question to ask (for the first post of this thread) would be:
Q1: Why did it take an entire line of code to solve the entire problem?
A1: If you can solve the problem with less than a line of code, tell me.

The sheer brilliance of the one-line solution notwithstanding, you actually replied to my second post, which was a script, which I wrote out of the kindness of my heart, to *help others* do what I can do, in a single line!

So the question to ask in the second post to which you replied, might be:
Q2: Can't you reduce the solution to less than a single line of code?
A2: By running that script, it solves the same problem for everyone.

Given that, please bear in mind that the goal was to efficiently solve the common problem that WSL commands are not Windows binaries in the path.

The fact I solved *that* problem in a single line of code, is brilliant.
Don't you think?
--
The great thing about Usenet is people work together to help all learn.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

If others wonder why I responded to "Frank Slootweg" the way I did, they
first need to know he's a common troll who has infested Usenet for decades.

Newsgroups: comp.mobile.android
Subject: Politely asking the Frank Slootweg common troll to cut it out
Date: Thu, 23 Oct 2025 12:34:40 -0600
Message-ID: <10ddsg0$1l6t$1@nnrp.usenet.blueworldhosting.com>

Nonetheless, in respect to the others whose intent is to benefit from
every Usenet thread, below is a response to what Frank Slootweg asked.

=====< First sentence from Frank who deserves a technical answer: >=====
And make sure that you can no longer run any of your Windows software? [1]

I think this was directed toward Lawrence's idea, which, I give Frank
credit for, since running grep on Windows versus running Linux are two completely different things.

As I had noted prior, the solution I propose is a single line.
To run Linux instead of a single line seems disproportionately off kilter.

=====< Second sentence from Frank who deserves a technical answer: >=====
But to the point: Don't confuse this convoluted methods
with what most others are doing.

I read that with disbelief, as Frank is apparently disproportionately off kilter in this second line, since he has no better of a solution.

So I must ask Frank Slootweg directly:
Q: How does he propose we solve this problem in less than a single line?
A: ?

If Frank Slootweg can't answer that question, then his remark that a single line is a "convoluted method" falls shockingly obviously flat, does it not?

=====< Third sentence from Frank who deserves a technical answer: >=====
There are many solutions for running Unix/UNIX/GNU commands on
Windows. Paul mentions one. I'm using another since well over two
decades (see User-Agent: header) and have been using similar solutions
since the early MS-DOS days. This is a total non-'problem'.

Regarding Paul's suggested solution, while Paul volunteered that
kind-hearted suggestion, it doesn't solve the stated problem at all.
a. You already have WSL
b. You want to use grep in adb copy/paste commands

If others didn't read the response to Paul's kind-hearted suggestion, grep isn't even included in the RUST suite, and, it's more than just one step.

That doesn't mean Microsoft Coreutils for Windows isn't useful for other purposes, but it doesn't solve the stated problem set of merging WSL & CLI.

BTW, I installed Microsoft Coreutils for Windows, so I will test it out.
But for other reasons, such as to understand more of how we can use it.

=====< Fourth sentence from Frank who deserves a technical answer: >=====
[1] This is one of them rhetorical thingies.

I think Frank is referring here to Lawrence's kind-hearted suggestion of
"just use Linux", but that was never going to be the answer to the problem.

The problem set was clearly stated (or so I had thought) in the OP:
A. WSL is already installed & the user merely wants to use it from the CLI
B. Many adb command examples are provided using pipes to things like grep

For *that* problem set, if anyone reading this can find a more elegant,
more brilliant, more simple solution than a single-line file, let us know!

The whole point of Usenet is to learn from & to teach each other.
--
Usenet is a team sport where each person adds unique value their own way.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Thu, 8/27/2026 12:45 PM, Maria Sophia wrote:

Paul wrote:

Isn't there some Rust version of GREP ? That's assuming the package
is available right now.

https://learn.microsoft.com/en-us/windows/core-utils/overview

Of all the various ways to do that, some tools have line ending problems,
and then a "native" routine becomes a better choice.

How that starts out (apparently), is it sniffs $0 when you run it
(its own filename). If it finds "grep.exe" then it knows you want grep.
If the filename was "sed.exe", it knows you want SED. By using hardlinks,
you can have executables with the "right names" for the job, and
then the storage space for the executable is one set of clusters. I have
one program I wrote for myself that works like that. The filename
can be "encode.exe" or "decode.exe" and that decides the function.

Hopefully, for anything line-ending-sensitive, that program will
do it the Windows way.

When I compared the gnuwin32 "gawk" to the WSL2 "gawk",
the gnuwin32 one was Windows endings, the WSL2 one was Linux endings.
When writing scripts in that language, a couple lines must be
added to the BEGIN preamble, to compensate for that.

By running in the Windows environment, you have all your "visible" RAM
to use. That makes scoping out limitations for a run, a little bit easier. >> It looks like my WSL2 right now, is using half of system memory,
and the swap file is 25% of that number.

Hi Paul,

Thanks for bringing up RUST which, um, I had not heard of prior.
<https://daily.dev/posts/microsoft-ships-native-linux-coreutils-for-windows-built-on-rust-ggfo0izh5>

The problem for me is most of the suggested adb commands I find on the net tend to use Linux commands to post process raw output, usually in a pipe.
adb shell top -b -n 1 | head -n 25
adb shell pm list packages -3 | cut -d: -f2

adb shell df -h | awk 'NR==1 || /\/data$/ {print $1, $5, $6}'

adb shell dumpsys battery | grep -E 'status|health|temperature|voltage'
etc.

We could run those Linux commands on the Android device, but it's a PITA.
adb shell 'dumpsys battery | grep level'

Looking up RUST, so that we all benefit, apparently Microsoft released Coreutils for Windows containing a set of Unix-style command-line tools built on the open-source uutils Rust project but not 'grep' or 'find'.
*Microsoft Coreutils for Windows: native Linux command-line tools*
<https://4sysops.com/archives/microsoft-coreutils-for-windows-native-linux-command-line-tools/>

Apparently these core Linux tools are installed on Windows using winget:

winget install Microsoft.Coreutils

Found Coreutils for Windows [Microsoft.Coreutils] Version 2026.6.16
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to,
third-party packages.
Downloading
https://github.com/microsoft/coreutils/releases/download/v2026.6.16/coreutils-2026.6.16-x64.exe
100% 4.87 MB / 4.87 MB
Successfully verified installer hash
Starting package install...
The installer will request to run as administrator. Expect a prompt.
Successfully installed

Then we need to add coreutils to the Windows path

setx PATH "%PATH%;C:\Program Files\coreutils"

SUCCESS: Specified value was saved.

According to the documents above, these apparently work well:
cat, cp, ls, mv, rm, pwd, sleep, hostname
These only partially work according to the documents:
date, echo, mkdir, rmdir, find
These apparently don't come with the core utils package:
dir, more, expand, kill, chmod, chown, chroot, nuhup, tty, who, timeout,
paste, expand, whoami

I just realized that Microsoft's Coreutils package doesn't give us
grep, sed, cut or awk, so we still need additional Linux-like packages.

Drat.
Nonetheless, I just installed the coreutils, but I haven't tested it yet.

The package definitions, you can see them in gnuwin32. This provides
a "framework" for "existence".

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

Coreutils only covers a range of common utilities.
GREP and Sed are separate packages in that tree.

Microsoft would have to spin those separately.

Winget may span more than one repository. As if I do this:

winget list

I don't see any Coreutils by doing that.

*******

You can see a newer version exists for GREP. And it has
a different "smell" than a GNUWIN32 one. Version 2.5.4 is
the decades old GNUWIN32 one. But there is a newer one... if
you can figure out how to get it or where it is stored.

https://github.com/microsoft/winget-pkgs/issues/148120

Paul

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia <mariasophia@comprehension.com> wrote:

Frank Slootweg wrote:

Don't confuse convoluted methods with what most others are doing.

Hi Frank,

You're so desperate to insult me that you didn't even read what I wrote.

There was no insult. Just my opinion - probably shared by many - of
your methods.

[...]

Hence, almost everything you said was factually dead wrong, Frank.

"almost everything"!? I wrote *one* line.

When you grow up, you'll learn to read what I had written to understand it.

Sorry to rain on your parade, but I fully understood what you wrote.
That's why I said what I said.

The fact you never could complete high school is telling in your posts.

Here we go again! That's *not* a "fact", but your continuous lie.
Heaven knows why you have to lie about such a thing.

Probably caused by the fact that I - like you claim - also had a high
level, highly paid, job in Silicon Valley. Pissing contests are SO
childish.

[More repetition deleted.]

You have no desire to help anyone, Frank.

The thankful responses I get, clearly prove otherwise.

You're a despicable sadistic wholly unprepossessing ignorant human being.

Please don't hold back and let it all out. BTW, I think what you just
wrote was an insult, but I could be wrong.

In your response, if any, please indicate you read & understood the method.

Yes, as mentioned above, of course I fully understood your method.

Otherwise, it's obvious that you only have your own disgusting purposes.

So that means that we're 'friends' again?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia wrote:

If anyone reading this already knows how coreutils compares to WSL,
please edify the rest of us as that's likely a very useful discussion.

While it's useful to consider a comparision of CoreUtils to WSL, this is OT
in terms of the original goal of this thread, which was, let's be clear:

a. The user already has WSL and just wants to use it in the Windows CLI
b. The user is constantly getting adb examples which pipe to Linux

For that, I'm surprised there is resistance to an elegant 1-line solution.

But... nonetheless...

Here's a quick summary of what I found comparing WSL to CoreUtils, given I myself, like most people here, have suffered the CYGWIN-style abominations.

Utilities compiled natively for Windows (like those from GnuWin32 or
individual ports) run as pure Win32 applications. They don't spin up a
Linux kernel layer so startup times are faster and they understand native Windows file paths (C:\Users\Name) out of the box without needing /mnt/c/ syntax conversion.

That's good.

With WSL, we are crossing the boundary between the Windows NT kernel and
the Linux kernel every time we execute a command. For simple piping tasks,
the overhead is negligible, but path translation can occasionally get
tricky if we randomly mix absolute Windows paths with Linux-native flags.

A quick summary of the two methods for the stated problem set might be:

If we're already in the Windows CLI and we just want to pipe adb to grep, keeping a brilliantly simple bridge script in the PATH is hard to beat.

However, if anyone can beat the simplicity of a one-line solution, let us
all know as solving the CLI pipe-to-grep problem has always been an issue.
--
Usenet is an assemblage of purposefully helpful people teaching each other.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Frank Slootweg wrote:

Sorry to rain on your parade, but I fully understood what you wrote.

Hi Frank,

Given your own personal assessment that you "fully understood" the clearly stated problem set and just as clearly stated proposed one-line solution,
what exactly is your counter proposal as a solution to the problem set?

And how is your proposed solution less "convoluted" than a 1-line bridge?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Paul <nospam@needed.invalid> wrote:

On Thu, 8/27/2026 12:45 PM, Maria Sophia wrote:

[...]

I just realized that Microsoft's Coreutils package doesn't give us
grep, sed, cut or awk, so we still need additional Linux-like packages.

Drat.
Nonetheless, I just installed the coreutils, but I haven't tested it yet.

The package definitions, you can see them in gnuwin32. This provides
a "framework" for "existence".

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

Coreutils only covers a range of common utilities.
GREP and Sed are separate packages in that tree.

I don't know what the fuss is about. The 'Coreutils for Windows' page
clearly says that it includes grep (and cut, but indeed not sed or awk).

<https://learn.microsoft.com/en-us/windows/core-utils/overview>

<https://learn.microsoft.com/en-us/windows/core-utils/commands>

grep is a different part of *uutils* (uutils/grep, not
uutils/coreutils), but *included* in 'Coreutils for Windows'.

Anyway, as mentioned, I prefer Cygwin, which is (modular and) more
complete than both 'Coreutils for Windows' and GnuWin.

[...]
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

At Thu, 27 Aug 2026 13:21:47 -0600, Maria Sophia <mariasophia@comprehension.com> wrote:

Frank Slootweg wrote:

Sorry to rain on your parade, but I fully understood what you
wrote.

Hi Frank,

Given your own personal assessment that you "fully understood" the
clearly stated problem set and just as clearly stated proposed
one-line solution, what exactly is your counter proposal as a
solution to the problem set?

And how is your proposed solution less "convoluted" than a 1-line
bridge?

Why don't you like Cygwin?
--
-v System76 Thelio Mega v1.1 x86_64 Mem: 258G
OS: Linux 7.2.1 D: Mint 22.3 DE: Xfce 4.18 (X11)
NVIDIA GeForce RTX 3090Ti (24G) (610.57.04)
"Reality seems to be a constant intrusion on my dreams!"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

At 27 Aug 2026 19:41:57 GMT, Frank Slootweg <this@ddress.is.invalid>
wrote:

Paul <nospam@needed.invalid> wrote:

On Thu, 8/27/2026 12:45 PM, Maria Sophia wrote:

[...]

I just realized that Microsoft's Coreutils package doesn't give
us grep, sed, cut or awk, so we still need additional Linux-like packages.

Drat. Nonetheless, I just installed the coreutils, but I haven't
tested it yet.

The package definitions, you can see them in gnuwin32. This provides
a "framework" for "existence".

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

Coreutils only covers a range of common utilities.
GREP and Sed are separate packages in that tree.

I don't know what the fuss is about. The 'Coreutils for Windows'
page
clearly says that it includes grep (and cut, but indeed not sed or
awk).

<https://learn.microsoft.com/en-us/windows/core-utils/overview>

<https://learn.microsoft.com/en-us/windows/core-utils/commands>

grep is a different part of *uutils* (uutils/grep, not
uutils/coreutils), but *included* in 'Coreutils for Windows'.

Anyway, as mentioned, I prefer Cygwin, which is (modular and) more
complete than both 'Coreutils for Windows' and GnuWin.

[...]

I'll note here that using the Cygwin grep(1) is a 0-line solution,
which is superior to running grep in an emulator.

"Maria" seems to have spent several articles patting himself on
the back. He could have used the time to install adb in WSL
and just do everything from Linux, natively.

HTH. HAND.
--
-v System76 Thelio Mega v1.1 x86_64 Mem: 258G
OS: Linux 7.2.1 D: Mint 22.3 DE: Xfce 4.18 (X11)
NVIDIA GeForce RTX 3090Ti (24G) (610.57.04)
"Death is natures way of telling you to slow down."
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia <mariasophia@comprehension.com> wrote:

Frank Slootweg wrote:

Sorry to rain on your parade, but I fully understood what you wrote.

Hi Frank,

Given your own personal assessment that you "fully understood" the clearly stated problem set and just as clearly stated proposed one-line solution, what exactly is your counter proposal as a solution to the problem set?

And how is your proposed solution less "convoluted" than a 1-line bridge?

As should have been obvious from the attributions, my response was
to *Lawrence's* comment:

"How many of these do you have to write before it becomes simpler just
to run a Linux system?"

My "proposed solution(s)" to *that* question were given in that same response.

Given *your* "stated problem" (which I did *not* respond to) and the
fact that you already have WSL2 with an Ubuntu installation, I can
understand that you opted for your "1-line bridge".

But as Lawrence hinted at, as a general solution - i.e. useful to
others (otherwise why bother with a pompous "PSA"?) - it's convoluted,
which became clear in your later post where you found yourself missing
more Unix commands, which would need more "1-line bridge"s.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Arlen,

While we've searched for decades to find any useful scripts from you,

And that is how its supposed to be. I *help*. I normally do not write someones code for them - as you should know by now.

I realize you've never been particularly reluctant to criticize my kind-hearted scripts

Don't bullshit us. Your "kind-hearted scripts" are more often convoluted
and ill thought-out danger-zones than not - as I have mentioned (and
sometimes also explained) multiple times.

such as this latest script which I wrote so that
others can run more easily most of the common WSL commands on Windows.

You included a script ? Where ?

I've tried to help you quite a number of times - and between the lines even here - but you always rejected such help.


And a freebee : have you already checked if that gvim equate method is permanent ? Or does it disappear the moment you close the command-console ?
I would check that if I where you ...

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Thu, 27 Aug 2026 11:53:33 -0600, Maria Sophia wrote:

But asking "why not use Linux" is absolutely the wrong question to
ask.

No, the question is rCLwhy not use it directlyrCY. Because rCLuse LinuxrCY is something yourCOre already doing, albeit in a convoluted way.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On 2026-08-27 20:39, Maria Sophia wrote:

If others wonder why I responded to "Frank Slootweg" the way I did, they first need to know he's a common troll who has infested Usenet for decades.

No, he is not.

Ignoring the rest of your post.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Thu, 27 Aug 2026 12:14:45 -0600, Maria Sophia wrote:

When I'm working at the Windows command line, I don't want to stop
and translate every Unix pipeline I encounter into Windows syntax.

Maybe it would be simpler to work at a Linux/Unix command line, then
you could skip this translation step.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On 2026-08-27 19:53, Maria Sophia wrote:

Lawrence D'Oliveiro wrote:

On Thu, 27 Aug 2026 00:05:41 -0600, Maria Sophia wrote:

Since this simple method should work for many common Linux
commands...

How many of these do you have to write before it becomes simpler just
to run a Linux system?

Hi Lawrence,

Rest assured I've used every operating system out there since the 1960s',
& I have "been there, done that", with dual-boot Linux/Windows long ago.

The record shows I've solved all sorts of cross-platform problems with a dual-boot Ubuntu (where, for example, it reads iOS files better'n Windows).

But asking "why not use Linux" is absolutely the wrong question to ask.

The right question to ask (for the first post of this thread) would be:
Q1: Why did it take an entire line of code to solve the entire problem?
A1: If you can solve the problem with less than a line of code, tell me.

The sheer brilliance of the one-line solution notwithstanding, you actually replied to my second post, which was a script, which I wrote out of the kindness of my heart, to *help others* do what I can do, in a single line!

So the question to ask in the second post to which you replied, might be:
Q2: Can't you reduce the solution to less than a single line of code?
A2: By running that script, it solves the same problem for everyone.

Given that, please bear in mind that the goal was to efficiently solve the common problem that WSL commands are not Windows binaries in the path.

The fact I solved *that* problem in a single line of code, is brilliant. Don't you think?

When one calls oneself brilliant, or doing brilliant solutions, I
suspect the reverse. It is bad manners to call oneself "brilliant".

I read your script, and your solution seemed to me obvious, even though
I don't use Windows.

Another method would be to archive all batch files in a single zip and
tell people to install that. You put the zip in a public server and tell people to download that.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On 2026-08-27 22:19, Lawrence DrCOOliveiro wrote:

On Thu, 27 Aug 2026 12:14:45 -0600, Maria Sophia wrote:

When I'm working at the Windows command line, I don't want to stop
and translate every Unix pipeline I encounter into Windows syntax.

Maybe it would be simpler to work at a Linux/Unix command line, then
you could skip this translation step.

Indeed. Using adb for Linux.
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Paul wrote:

The package definitions, you can see them in gnuwin32. This provides
a "framework" for "existence".

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

Coreutils only covers a range of common utilities.
GREP and Sed are separate packages in that tree.

Microsoft would have to spin those separately.

Winget may span more than one repository. As if I do this:

winget list

I don't see any Coreutils by doing that.

*******

You can see a newer version exists for GREP. And it has
a different "smell" than a GNUWIN32 one. Version 2.5.4 is
the decades old GNUWIN32 one. But there is a newer one... if
you can figure out how to get it or where it is stored.

https://github.com/microsoft/winget-pkgs/issues/148120

Hi Paul,

You're always purposefully helpful and you provide data, like I do, that
others can always benefit from, so I thank you for bringing up coreutils.

As I noted, I installed it, but I haven't tested it yet, much like I
installed WSL (long ago) to solve some problem or other & just left it.

If I "like" coreutils, I might get that grep you speak of, but as we all
know, all of us have been using CYGWIN abominations or Git Bash (MSYS2.

Hell, most of us already have PowerShell aliases for many Linux commands.

The SUBJECT of this thread is not "HOW TO RUN LINUX ON WINDOWS", but
*How to run existing WSL commands on the Windows CLI*

That's the problem set that an elegant one-line file accomplishes.
Which, if you ask me, I think is pretty neat.

It doesn't mean that's the only way to do it though.
There may be more elegant solutions than adding a 1-line file to the path.

But, most of the time, "grep" is the main command that is needed.
Mainly because adb often dumps huge amounts of output to the screen.

The script I wrote adds a few more commands to the WSL:CLI bridge.
But I wrote that script mostly to help others accomplish it easily.

For most situations, "grep" is the main command in adb examples.

Given that, the proposed one-line solution works for anyone...
a. Who already has WSL installed on Windows
b. And who simply wants to run adb commands piped to grep

The solution was *never* to re-write Windows to use all Linux commands.
We could do that. For sure we could do it. But it's not the point here.

Still... I thank you for coreutils, and for the advice where to get grep. Separately I'll test out those coreutils to see how they compare to WSL.

If anyone reading this already knows how coreutils compares to WSL,
please edify the rest of us as that's likely a very useful discussion.
--
Usenet is a team sport where each person adds unique value their own way.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

vallor wrote:

I'll note here that using the Cygwin grep(1) is a 0-line solution,
which is superior to running grep in an emulator.

... could have used the time to install adb in WSL
and just do everything from Linux, natively.

Hi "vallor",

Thank you for the alternative proposals, even if they missed the target.

Both your suggestions were attempts to solve the problem, which is
appreciated because Usenet is very unkind to people who try to help.

To answer your first point, there's nothing wrong with the classic
cygwin1.dll POSIX emulation layer (which most of us used as ported GNU coreutils three decades ago, which is well before WSL even existed).

But that emulation-layer abomination isn't the topic of this thread.

The topic, as stated in the subject, is bridging WSL to the Windows CLI. Specifically:
a. The user already has WSL installed.
b. The goal is simply to run native Linux WSL calls from the Windows CLI
(using grep as the primary example).

The thread is NOT about the best way to turn Windows into Linux, nor is it about debating the well-known POSIX-to-Win32 translation abominations.

The goal is to run this command using the WSL layer in CLI:

adb shell pm list packages | grep -i gsf

in the simplest way possible, given the WSL layer already exists.

All this thread does is suggest a brilliant way to bridge that gap.
Using a single line file, called "grep.cmd" containing @wsl grep %*

I came up with that solution on my own, but if others know of an even
easier, even simpler solution than that one-line file, let us all know!

As for your second helpful suggestion of shifting the entire workflow into
a Linux VM, that's pretty much what Lawrence had kindly suggested.

While there's nothing wrong with a native Linux flow, that's NOT what this thread is about, where, I repeat, what this thread is about is it's a
public service announcement about an elegant 1-line solution that bridges
the gap instantly between the existing WSL and the Windows command line.

To be fair to you, you may not be aware that I run adb over Wi-Fi because
my USB port is broken. The Windows host is already connected to the phone's TCP/IP daemon. Suggesting we "just install adb in WSL" means managing a completely separate Android SDK installation, daemon lifecycle, and port-forwarding bridge inside Linux-all just to run:

adb shell pm list packages | grep -i gsf

By contrast, the one-line wrapper script (grep.cmd containing @wsl grep %*) keeps the adb tool where the network connection lives (cmd) while borrowing the parser we actually want.

It's actually a brilliantly simple lightweight, pragmatic fix, IMHO.

In summary, thank you for the idea of using the cygwin layer that I gave up on, oh, maybe not thirty years ago, but somewhere between twenty years ago
and about a decade ago, where I never want to use that abomination again.

However, both your kindly suggested ideas were worth looking at, so I appreciate that you tried to help, where the conversation helps all of us.
--
On Usenet, we find people who come with vast backgrounds in systems design
.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Thu, 27 Aug 2026 14:44:23 -0400, Paul wrote:

Winget may span more than one repository. As if I do this:

winget list

I don't see any Coreutils by doing that.

I understand what Microsoft have actually done is port the Rust-based
remake of Coreutils, rather than the original versions written in C.

I further understand that there are some inadvertent incompatibilities
in the Rust-based Coreutils, which has caused Ubuntu to revert
embracing them and go back to the original versions.

<https://linuxiac.com/ubuntu-reverts-rust-cp-after-it-breaks-live-image-builds/>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Frank Slootweg wrote:

Coreutils only covers a range of common utilities.
GREP and Sed are separate packages in that tree.

I don't know what the fuss is about. The 'Coreutils for Windows' page clearly says that it includes grep (and cut, but indeed not sed or awk).

<https://learn.microsoft.com/en-us/windows/core-utils/overview> <https://learn.microsoft.com/en-us/windows/core-utils/commands>

grep is a different part of *uutils* (uutils/grep, not
uutils/coreutils), but *included* in 'Coreutils for Windows'.

Anyway, as mentioned, I prefer Cygwin, which is (modular and) more
complete than both 'Coreutils for Windows' and GnuWin.

Thank you Frank for suggesting we look up if grep resides in coreutils.
Ah. I just tested grep for the first time to see if it's in coreutils.

Woo hoo!
As Frank noted, grep is there!

C:\> where grep
C:\Program Files\coreutils\bin\grep.exe
C:\Users\username\adb\grep.cmd

Hence, an apology is due to both Frank & Paul since I had installed
coreUtils for Windows while I was reading Paul's kind and helpful
suggestion, but I clearly said I had not *tested* them at the time.
C:\> winget install Microsoft.Coreutils
C:\> setx PATH "%PATH%;C:\Program Files\coreutils"

The documentation I read (and cited) seemed to say grep wasn't part of the
core utils, to which Frank has just responded to, as I was wrong on that.

Interestingly, all the grep commands I used today from inside the Windows command line are actually, based on that, coming from the core utils!

Even more interesting is Frank's helpful suggestion about sed & awk!
C:\> where sed
C:\Users\username\adb\sed.cmd
C:\> where awk
C:\Users\username\adb\awk.cmd
C:\> where tr
C:\Program Files\coreutils\bin\tr.exe
C:\Users\username\adb\tr.cmd

So let's test the coreutils that I mentioned to Paul were not tested!

In summary, I think Paul's idea of coreutils (with the caveats Frank
mentioned about grep, awk & sed taken into account) is useful to test!

Thank you both Frank and Paul for bringing up that coreutils has grep!
--
Usenet is a community of kind hearted people who help each other learn.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Thu, 8/27/2026 9:21 PM, Lawrence DrCOOliveiro wrote:

On Thu, 27 Aug 2026 14:44:23 -0400, Paul wrote:

Winget may span more than one repository. As if I do this:

winget list

I don't see any Coreutils by doing that.

I understand what Microsoft have actually done is port the Rust-based
remake of Coreutils, rather than the original versions written in C.

I further understand that there are some inadvertent incompatibilities
in the Rust-based Coreutils, which has caused Ubuntu to revert
embracing them and go back to the original versions.

<https://linuxiac.com/ubuntu-reverts-rust-cp-after-it-breaks-live-image-builds/>

A topic like this, is a bit like explaining wine selection,
to people who don't drink wine. You have to do your research
and select a good vintage.

At least with cygwin, you used to see some amount of curation,
some amount of organization. The x86 version, I liked that and
had installed it several times over the years. But when that
was discontinued and an x64 version showed up, I installed
that one day, and there was some disconcerting network activity,
(something you never saw on the x86 version), I uninstalled it
and that was the last Cygwin here. But other than that, at least
you have a lineup of stuff that's all been tested and packages
managed.

The winget thing, I have no idea if it has any concept of
"Repository" or it just "shops at the 7-11 and the Dollar Store".
It seems to be downloading from Sourceforge. Working with Sourceforge
is fine, as long as you do some amount of investigation before
the install step. A thing like WinGet as a concept, to be shooting
from the hip like that, the Repository used must be well maintained
to be that trusting. And finding it downloading from Sourceforge
does not inspire confidence. I have no idea what the folks at
Sourceforge do, to ensure no supply side attacks. I could understand this behavior, if say, Microsoft had bought Sourceforge.

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Carlos E. R. wrote:

When I'm working at the Windows command line, I don't want to stop
and translate every Unix pipeline I encounter into Windows syntax.

Maybe it would be simpler to work at a Linux/Unix command line, then
you could skip this translation step.

Indeed. Using adb for Linux.

Thank you Carlos & Lawrence for your kind suggestions for improvement!
All these suggestions are welcome as they improve our interop capabilities.

1. Circa 1996 GNU utils/POSIX compatibility layer (e.g., Cygwin)
2. Late 1990s/early 2000s Linux OS inside a conventional VMware VM
(1999 VMware Workstation, 2007 VirtualBox, 2008 Hyper-V, etc.)
3. Circa 2016 WSL 1 translation layer (allowing @wsl wrappers)
4. Circa 2020 WSL 2 (real Linux kernel inside a lightweight VM)
5. Mid 2026 Microsoft's native Rust-based Coreutils for Windows

While this helpful suggestion posed by multiple people of setting up adb
inside a Linux VM to talk to the phone hardware over native Linux adb
protocols might be worthwhile, we also have to remember our combined experiences with VMs and physical hardware in the past.

I, for one, have wasted far too many hours trying to make VMs work. Particularly when they need to use PC hardware to access outside devices.

At least in my experience, that implies that a Linux VM can be an even
worse implementation than Cygwin, but for very different reasons.

The problem isn't running Linux inside the VM, mind you. The problem is the boundary between the guest and the Windows host, especially when physical devices and native Windows executables are involved.

For my use case, I want Linux tooling inside the Windows command-line environment, without giving up the Windows environment I'm actually working
in.

WSL 1 gives us a Linux userspace and, with WSL 2, a real Linux kernel.
At the same time, we can still work with Windows processes, files, devices,
and tools, which is where I have found VM solutions lacking in the past.

As for the suggestion of Cygwin, I've been there and done that, but I admit
I gave up on Cygwin maybe, oh, fifteen or even twenty five years ago, and haven't looked back to see if Cygwin has fundamentally improved since then.

Cygwin has a different problem than running Linux inside of a VM.

Cygwin creates a POSIX-compatibility environment on top of Windows, which
can introduce mismatches in handle mapping and line endings (\r\n vs \n)
when piping output directly from a native Win32 executable such as adb.exe.

Certainly we can make Cygwin work, but, as I noted, I gave up on Cygwin
decades ago, so unless it has improved greatly, it's not what I'll test.

That's ultimately why my helpful public-service announcement was focused on
WSL but I do think now, after testing briefly Paul's and Frank's suggestion
of the brand new Microsoft CoreUtils, that they may be a simpler solution.

In reality, given the paucity of coreUtils implementations, (e.g., my
CoreUtils has grep, but not awk or sed), I think a possible solution is to combine both the WSL and CoreUtils capabilities, if the tests work out.
C:\> winget install Microsoft.Coreutils
C:\> setx PATH "%PATH%;C:\Program Files\coreutils"

C:\> where grep
C:\Program Files\coreutils\bin\grep.exe
C:\Users\username\adb\grep.cmd

C:\> where sed
C:\Users\username\adb\sed.cmd

C:\> where awk
C:\Users\username\adb\awk.cmd

C:\> where tr
C:\Program Files\coreutils\bin\tr.exe
C:\Users\username\adb\tr.cmd

Since this detailed agreement is long, I'll test representative
adb commands using the above Linux commands to see how it works out.

Thank you Carlos & Lawrence for your kind suggestions for improvement!
--
Usenet isn't for amusement; it's for learning from and teaching each other.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

R.Wieser wrote:

You included a script ? Where ?

Here...

Newsgroups: alt.comp.os.windows-10,comp.mobile.android,alt.msdos.batch,alt.os.linux
Subject: Re: PSA: How to add WSL grep to the Windwos command-line PATH
Date: Thu, 27 Aug 2026 00:05:41 -0600
Message-ID: <116ok3j$1n21$1@nnrp.usenet.blueworldhosting.com>

Furthermore, below is the comment section which explains what it does...

:: ------------------------------------------------------------------------
:: wsl2cli.bat
:: Bridge common WSL Linux utilities into Windows CMD/PowerShell by
:: generating wrapper scripts in Windows that call existing WSL binaries
:: ------------------------------------------------------------------------
:: v1p8 20260826 Added keyword support (exit, quit, q) for graceful exit
:: v1p7 20260826 Switched echo. to echo: to prevent command interpreter quirks
:: v1p6 20260826 Commented out debug lines for clean production output
:: v1p5 20260826 Added ignore of empty-path tokens from trailing semicolons
:: v1p4 20260826 Added debug tracking lines inside the PATH parsing loop
:: v1p3 20260826 Fixed path evaluation bug by quoting paths in the loop
:: v1p2 20260826 Output the current PATH filespecs for easier selection
:: v1p1 20260826 Added ability to put cmd files where desired by number
:: v1p0 20260826 Make Linux commands that work in CMD using WSL calls
:: ------------------------------------------------------------------------

Basically, it allows anyone on Windows with WSL already installed to run
any of the given Linux commands after executing this single setup script.
--
The job of a Usenet post is to add useful value each time we communicate.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

vallor wrote:

And how is your proposed solution less "convoluted" than a 1-line
bridge?

Why don't you like Cygwin?

Hi vallor,

Good question!

I don't know of you like I know of all the others, so I'll give you an
answer that brings in my vast experience with Linux & Windows over decades.

I'm sure your experience is just as vast as mine, and even more vast
perhaps, which is why this discussion has taken a nice turn of events once
Paul pointed out the brand new (just released this summer!) CoreUtils.
*Microsoft's Coreutils for Windows first came out on June 2, 2026*

Let's be clear that most of us, including myself, have used the various solutions to obtain the basic Linux commands inside of the Windows CLI.

1. Circa 1996 GNU utils/POSIX compatibility layer (e.g., Cygwin)
2. Late 1990s/early 2000s Linux OS inside a conventional VMware VM
(1999 VMware Workstation, 2007 VirtualBox, 2008 Hyper-V, etc.)
3. Early 2000s to about 2005, GRUB/Linux accessing Windows filesys
(my dual-boot Ubuntu, for example, accessed 99.9% of Windows files)
3. Circa 2016 WSL 1 translation layer (allowing @wsl wrappers)
4. Circa 2020 WSL 2 (real Linux kernel inside a lightweight VM)
5. Mid 2026 Microsoft's native Rust-based Coreutils for Windows

To give you a brief overview of my experience level, in the 1960's I
learned computing on IBM 1130 and IBM 360 refrigerated mainframes before flipping the boot-switches on the bottom of a PDP 11 in the 1970s.

My first "workstation" was a DEC VAX / VMS in the late 1970s, and then a "personal workstation" of Masscomp in the early 1980s, which graduated to
SunOS in the rest of the 1980s to Solaris pizza boxes in the early 1990s.

By the mid 1990s I was dual booting my own Red Hat Linux & Windows laptops, but, like most here, in the 1980s and 1990s I also owned an assemblage of
IBM PC implementations where my hero, at the time, was Peter Norton.

Sprinkled among the Windows PCs were Apple Macintosh abominations, where I still have the "portable Mac" black case that is as tall as a laundry bag.

I, for one, always thought Linux, being free and rather capable, would outcompete Windows, but alas, there's power to corporate MSOffice that is undeniably sticky, to the point that Linux is mostly servers, not desktops.

Having said all that by way of introduction, my dislike of Cygwin goes way back, oh, maybe fifteen or twenty (or so) years ago, where I do very much
like what Paul had suggested, which apparently only released a month ago.

In fact, had I know about Paul's suggestion of CoreUtils ahead of time, I probably would have incorporated them into the public service announcement.

As I think now, perhaps the simplest solution, will be to combine the power
of the coreutils (for items like grep) with WSL (for items like awk/sed).

Dunno yet, but it should be clear I'm not going backward to Cygwin dlls.
--
The kind of people who post to Usenet are a dying breed of helpful people.
























--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Thu, 27 Aug 2026 19:37:23 -0600, Maria Sophia wrote:

Thank you Frank for suggesting we look up if grep resides in
coreutils. Ah. I just tested grep for the first time to see if it's
in coreutils.

Woo hoo!
As Frank noted, grep is there!

C:\> where grep
C:\Program Files\coreutils\bin\grep.exe
C:\Users\username\adb\grep.cmd

Not in Linux, itrCOs not:

ldo@hypatia:~> dpkg-query -S $(type -p grep)
grep: /usr/bin/grep

ldo@hypatia:~> dpkg-query -S $(type -p cp)
coreutils: /usr/bin/cp
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence D Oliveiro wrote:

But asking "why not use Linux" is absolutely the wrong question to
ask.

No, the question is |why not use it directlyi. Because |use Linuxi is something you re already doing, albeit in a convoluted way.

Hi Lawrence,

I know you're sincere, as we've had detailed productive ground-breaking discussions on a variety of newsgroup including Firefox, Python & here.

You should be aware by now that I present the actual facts, and I do
not whitewash them or hide what doesn't fit any given personal bias.

I only care to come to the best logically sensible defensible solution.

You're also aware that I can easily change my mind, like any scientist.
All I have to do is be told of a better solution for the problem set.

And, as you can likely tell, I'm all about solving interoperability issues. Specifically, in this case, adb for Android on Windows with Linux commands.

As you likely may be aware, my experience with "unix" is similar to that of any octogenarian of today in the Silicon Valley, in that I've used 'em all.

Linux is great. Certainly the ability to use grep/sed/awk/tr/etc. is great.
And there's no doubt adb command examples make extensive use of those too.

I only learned about the brand new Microsoft CoreUtils yesterday from Paul. Frank pointed out that they have grep, so, I'm already using that grep.


While I only learned about it from Paul, apparently Microsoft's Rust
CoreUtils intentionally only implements core GNU file/text utilities (like grep, tr, cat, head) leaving POSIX text processors like awk & sed to WSL.

So I'm currently using a combination of @WSL and CoreUtils, e.g., .
C:\> where grep
C:\Program Files\coreutils\bin\grep.exe
C:\Users\username\adb\grep.cmd
C:\> where sed
C:\Users\username\adb\sed.cmd
Apparently sed is NOT in coreutils, so let's use @WSL
C:\> where awk
C:\Users\username\adb\awk.cmd
Apparently awk is NOT in coreutils, so let's use @WSL
C:\> where tr
C:\Program Files\coreutils\bin\tr.exe
C:\Users\username\adb\tr.cmd

Let's test it out to see how well or poorly the current setup is working:
C:\> adb shell dumpsys battery | grep level
level: 95 (where "level" is in red)

C:\> adb shell pm list packages | sed "s/package://g" | grep filemanager
za.kilowatch.ultimatefilemanager
com.amaze.filemanager
com.simplemobiletools.filemanager.pro
org.openintents.filemanager
org.fossify.filemanager
(where the "filemanager" grep term shows up in red letters"

C:\> adb shell pm list packages | tr "." "-"|grep filemanager
package:za-kilowatch-ultimatefilemanager
package:com-amaze-filemanager
package:com-simplemobiletools-filemanager-pro
package:org-openintents-filemanager
package:org-fossify-filemanager

While those sample commands all worked quite nicely, a bigger
problem seems to be "awk" isn't working like I would like though.

C:\> adb shell dumpsys battery | wsl awk "/level:/ {print \"LEN:\", length($2), \"VAL:\", $2}"
awk: cmd. line:1: /level:/ {print "LEN:", length(), "VAL:", }
awk: cmd. line:1: ^ syntax error

So it may be better for awk to just pass it to the Android Linux kernel:
C:\> adb shell "dumpsys battery | awk '/level:/ {print \"Battery Level:\", $2 \"%\"}'"
Battery Level: 94%

I took a look at the octal dump of the battery output & it's nasty.
C:\> adb shell dumpsys battery | wsl od -c

In summary, for *simple* commands, the WSL/CoreUtils approach works.
But for more complex commands (such as awk), it does not work well.

Sigh.
--
Usenet is where kind-hearted well-educated people gather to exchange ideas.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Thu, 27 Aug 2026 20:33:13 -0600, Maria Sophia wrote:

At least in my experience, that implies that a Linux VM can be an
even worse implementation than Cygwin, but for very different
reasons.

Linux VMs are used heavily in mission-critical deployments.

Your experience might explain why even MicrosoftrCOs cloud is
predominantly Linux-based rather than Windows-based.

I have a client running essentially his entire business on this <https://xcp-ng.org/>, with this <https://xen-orchestra.com/> as the
GUI front-end.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Thu, 27 Aug 2026 21:11:58 -0600, Maria Sophia wrote:

I, for one, always thought Linux, being free and rather capable,
would outcompete Windows, but alas, there's power to corporate
MSOffice that is undeniably sticky, to the point that Linux is
mostly servers, not desktops.

Microsoft seems to be moving away from rCLMicrosoft OfficerCY towards rCLMicrosoft 365rCY. And the latter lists Linux as an officially-supported platform.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Carlos E. R. wrote:

I read your script, and your solution seemed to me obvious, even though
I don't use Windows.

Hi Carlos,

If you don't use Windows, then you might not easily see how it's not always obvious how to run Linux commands from the Windows command line interface.
adb -> stdout -> Unix filter (grep, sed, awk, etc.)

If it were always obvious, there wouldn't be so many attempts at solutions.

1. Circa 1996 GNU utils/POSIX compatibility layer (e.g., Cygwin)
2. Late 1990s/early 2000s Linux OS inside a conventional VMware VM
(1999 VMware Workstation, 2007 VirtualBox, 2008 Hyper-V, etc.)
3. Early 2000s to about 2005, GRUB/Linux accessing Windows filesys
(my dual-boot Ubuntu, for example, accessed 99.9% of Windows files)
3. Circa 2016 WSL 1 translation layer (allowing @wsl wrappers)
4. Circa 2020 WSL 2 (real Linux kernel inside a lightweight VM)
5. Mid 2026 Microsoft's native Rust-based Coreutils for Windows

Do you use adb from your Linux desktop to work with your Android phone?
I'm specifically wondering about the adb | grep type of workflow.

Most of the adb examples on the web assume Unix tools such as grep, sed or
awk are available in the shell. That grep/sed/awk combination is completely natural on the Linux side but less natural from a Windows command prompt.

The noble quest is to make that completely natural on the Windows CLI.
With Paul's CoreUtils solution & my WSL solution, we're almost there now.

It's really just awk that is not behaving as well as we'd like it to.
--
On Usenet, we can pool our knowledge and skills so everyong learns more.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence DoOliveiro wrote:

I understand what Microsoft have actually done is port the
Rust-based remake of Coreutils, rather than the original versions
written in C.

I further understand that there are some inadvertent
incompatibilities in the Rust-based Coreutils, which has caused
Ubuntu to revert embracing them and go back to the original
versions.

<https://linuxiac.com/ubuntu-reverts-rust-cp-after-it-breaks-live-image-builds/>

A topic like this, is a bit like explaining wine selection, to
people who don't drink wine. You have to do your research and select
a good vintage.

The cp(1) command is documented to work a certain way. The C version
does that, the Rust version doesnot.

<https://manpages.debian.org/cp(1)>

I only heard of the "rust coreutils" yesterday, but from what I gather, it seems that Rust Coreutils isn't "Linux technology brought to Windows" so
much as a cross-platform reimplementation of the Unix/GNU utilities,
written once in Rust and compiled for different operating systems. .

Hence I would agree with anyone who logically sensibly assserts that the
Rust CoreUtils should work the way commands are documented to work.

Regarding someone's comment about winget and core utils, this is useful:

winget list | grep -i coreutils

Coreutils for Windows version 2026.6.16 Microsoft.Coreutils 2026.6.16 winget

It appears to be brand new stuff as of June 16, 2026 (apparently).

I like the idea of using CoreUtils in Windows because it has
apparently a robust version of grep, but it doesn't have awk (AFAIK).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Thu, 27 Aug 2026 23:12:20 -0600, Maria Sophia wrote:

Most of the adb examples on the web assume Unix tools such as grep,
sed or awk are available in the shell. That grep/sed/awk combination
is completely natural on the Linux side but less natural from a
Windows command prompt.

The noble quest is to make that completely natural on the Windows
CLI. With Paul's CoreUtils solution & my WSL solution, we're almost
there now.

There are fundamental limitations on Windows which prevent that from
ever being a mainstream solution.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence DoOliveiro wrote:

The noble quest is to make that completely natural on the Windows
CLI. With Paul's CoreUtils solution & my WSL solution, we're almost
there now.

There are fundamental limitations on Windows which prevent that from
ever being a mainstream solution.

Yeah. I realized that. Even with WSL & CoreUtils.
Only the simplest of awk commands worked.

But, the good news is most of the time, we're just using grep.

So there's value given how easy it is to add the Rust Coreutils to Windows coupled with how easy it is to add the @wsl commands to the command line.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On 8/28/2026 3:18 AM, Maria Sophia wrote:

All this thread does is suggest a brilliant way to bridge that gap.
Using a single line file, called "grep.cmd" containing @wsl grep %*

I came up with that solution on my own, but if others know of an even
easier, even simpler solution than that one-line file, let us all know!

I don't use WSL nor doskey, but doesn't a simple

doskey grep=wsl grep

what you want? No need for a batch file and maybe problems
with poisoned characters (%^...) in %*. And you can automatically
load the doskey commands at startup of CMD.EXE.



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Arlen,

[re-inserted from my previous post]

such as this latest script which I wrote so that others
can run more easily most of the common WSL commands on Windows.

[end re-insert]

You included a script ? Where ?

Here...

[snip]

Ah yes. Not quoting what I replied to, and than trying to make it sound as
if my response/question was about something else altogether.

Not at all obvious ofcourse. no sir, not at all ! :-D

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Herbert Kleebauer wrote:

All this thread does is suggest a brilliant way to bridge that gap.
Using a single line file, called "grep.cmd" containing @wsl grep %*

I came up with that solution on my own, but if others know of an even
easier, even simpler solution than that one-line file, let us all know!

I don't use WSL nor doskey, but doesn't a simple

doskey grep=wsl grep

what you want? No need for a batch file and maybe problems
with poisoned characters (%^...) in %*. And you can automatically
load the doskey commands at startup of CMD.EXE.

Hi Herbert,

Thanks for that doskey suggestion of doskey grep=wsl grep

Over the years I've used almost every one of your suggestions, where only recently I retired the clever method you showed me of opening sans console
showwin.exe 5
del showwin.exe
goto :eof

I don't even remember if I ever knew about doskey, so I had to look it up.
doskey grep=wsl grep $*
Where $* is doskey's macro syntax for all arguments supplied to the macro.

Looking it up, doskey is elegant but it's quite different in how it works.

For example, we have to arrange for the macro to be installed in each CMD session, which isn't difficult to do, but the @wsl method is in the path.

However, your point about poisoning is indeed valid, as .cmd file is
subject to cmd.exe's parsing and expansion rules. So the wrapper isn't a transparent Unix-to-Windows argument-passing mechanism either.

There will be edge cases involving quoting, metacharacters, %, ^, etc., as we've found out in spades for the previous awk.cmd examples tested earlier.

For grep, Paul's suggestion of using the brand new Microsoft Rust CoreUtils (which were just released this summer) seems to be the simplest solution.
C:\> winget install Microsoft.Coreutils

Unfortunately, that doesn't work for awk either, as, for whatever reason, Microsoft didn't add the awk or sed commands, so I'm using WSL for sed.

So far, grep, sed & tr worked well in my tests, but awk failed miserably.

Thank you for your helpful suggestion of using doskey, as that was an idea
I had not even thought of, where it's nice everyone volunteered advice.
--
Usenet is where people with vast knowledge converge to discuss ideas.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On 8/28/2026 5:51 PM, Maria Sophia wrote:

Herbert Kleebauer wrote:

For example, we have to arrange for the macro to be installed in each CMD session, which isn't difficult to do, but the @wsl method is in the path.

If you want to use grep within a batch, you can also write the
doskey command at the top of the batch file and in the batch
itself you use the normal grep command. This way only wsl has
to be installed, no need to also copy batch files to a new PC.

But your grep.cmd solution would only work within a batch if
you write:

call grep

but then it would be easier (I think, you like to type a character less)
to just write:

wsl grep




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia wrote:

Then we need to add coreutils to the Windows path

setx PATH "%PATH%;C:\Program Files\coreutils"

SUCCESS: Specified value was saved.

WARNING!

Drat. That was a mistake!
C:\> echo %PATH%
Reports coreutils, then stuff, the same stuff, and coreutils again

That setx method was the wrong method, but worse, it wasn't even needed!

Since the purpose of this thread is to be a public service announcement to help others run Linux commands like "grep" on the CLI, notethat the setx
above duplicated the path, and worse, the winget of coreutils added the coreutils to the BEGINNING of the path, so, the end result was:
a. CoreUtils was in the beginning of the path
b. Then the old path was duplicated
c. And CoreUtils was added to the end of the path

So, the main advice here is to know that CoreUtils takes care of the path.

What comes now in this article is simply how to fix it if you did it.
1. Back up the path
reg export HKCU\Environment "%USERPROFILE%\path-backup.reg" /y

2. De-duplicate the user path but still preserve the original order
powershell -NoProfile -Command "$u=[Environment]::GetEnvironmentVariable('Path','User') -split ';' | ? {$_}; $m=[Environment]::GetEnvironmentVariable('Path','Machine') -split ';' | ? {$_}; $u=$u | ? {$_ -notin $m} | Select-Object -Unique; [Environment]::SetEnvironmentVariable('Path',($u -join ';'),'User')"

3. Remove the coreutils that was added at the end of the path
powershell -NoProfile -Command "$p=[Environment]::GetEnvironmentVariable('Path','User') -split ';' | ? { $_ -and $_ -ne 'C:\Program Files\coreutils' }; [Environment]::SetEnvironmentVariable('Path',($p -join ';'),'User')"

4. Check the path
echo %PATH%

In summary, when you install the Microsoft CoreUtils, it appends the
coreutils to the path for you so you don't have to do it yourself.
--
The only people who don't make a mistake are those who don't do anything.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence DoOliveiro wrote:

As Frank noted, grep is there!

C:\> where grep
C:\Program Files\coreutils\bin\grep.exe
C:\Users\username\adb\grep.cmd

Not in Linux, itos not:

ldo@hypatia:~> dpkg-query -S $(type -p grep)
grep: /usr/bin/grep

ldo@hypatia:~> dpkg-query -S $(type -p cp)
coreutils: /usr/bin/cp

Hi Lawrence,

Ah, I think I see your point. Thanks for brining it up so clearly.

In your Debian system:
/usr/bin/cp is supplied by the Debian coreutils package
/usr/bin/grep is supplied by a separate Debian grep package
That's a useful distinction which Windows owners should take note of.

I think your astute point may have been to let us know that I was
accidentally conflating Microsoft's package name, Coreutils, with the traditional GNU/Linux coreutils package.

You showed that in GNU/Linux, grep isn't part of GNU Coreutils.
It's a separate GNU project/package:
coreutils -> cp, mv, rm, cat, ...
grep -> grep

So I think what you're intimating is that this newly released set of
Windows Coreutils shouldn't be thought of as simply the Linux coreutils package for Windows as it is a collection of utilities which are different.

Specifically, the Microsoft CoreUtils grep comes from the Rust uutils/grep project rather than from the GNU grep project, is that right?

It seems the Microsoft repository says that its grep is based on a fork of uutils/grep, while most of the other utilities come from uutils/coreutils:
<https://github.com/microsoft/coreutils/blob/main/CONTRIBUTING.md>

That's all new to me as I only learned about Microsoft's Coreutils package from Paul this week. The first release appears to have been June 2, 2026:
<https://github.com/microsoft/coreutils/discussions/4>

Had I known about this package, that Paul was hiding from us (jk), I would have written a PSA about using it, instead of bridging WSL to the CLI.

Speaking of the public service announcement, since I didn't know about the Microsoft CoreUtils until Paul mentioned them, the only reason to even consider this PSA going forward are for the commands NOT in CoreUtils.

That's because Microsoft's utilities are native Windows executables,
whereas my original grep.cmd was merely a wrapper that bridged from Windows into WSL to run the Linux binary (but the sed.cmd" is still useful).
<https://learn.microsoft.com/en-us/windows/core-utils/overview>

So I'm going to revise the recommendation in the PSA.

1. For grep at least, the much cleaner solution now seems to be
simply installing Microsoft's Coreutils rather than maintaining
a grep.cmd wrapper around WSL.
<https://github.com/microsoft/coreutils/releases/download/v2026.6.16/coreutils-2026.6.16-x64.exe>
2. For sed, it seems (so far) the sed.cmd @WSL method is working
3. But, we still need a better solution for awk.

Luckily, the main need, at least for the stated problem set of
running adb examples found on the net, is mostly for just grep.

Thanks for pointing out the distinctions!
--
On Usenet, we teach what we know & then others teach us what we didn't know. --- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On 8/28/2026 7:13 PM, Maria Sophia wrote:

The goal of this PSA is to bridge Windows with Linux so that common
adb examples found on the Internet can be pasted, verbatim, into the CLI.

I think, the correct solution is, to install Linux in a virtual
machine. On your next PC install Linux as main OS and Windows in
a virtual machine. And then, in any further PC, you only need Linux.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia <mariasophia@comprehension.com> wrote:

If others wonder why I responded to "Frank Slootweg" the way I did, they first need to know he's a common troll who has infested Usenet for decades.

I hope you like the pie and egg.

[...]
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Herbert Kleebauer wrote:

If you want to use grep within a batch, you can also write the
doskey command at the top of the batch file and in the batch
itself you use the normal grep command. This way only wsl has
to be installed, no need to also copy batch files to a new PC.

But your grep.cmd solution would only work within a batch if
you write:

call grep

but then it would be easier (I think, you like to type a character less)
to just write:

wsl grep

Hi Herbert,

The goal of this PSA is to bridge Windows with Linux so that common
adb examples found on the Internet can be pasted, verbatim, into the CLI.

To that end, I very much appreciate Paul's suggestion of CoreUtils,
and your suggestion of DosKey to improve the connection of Linux:Windows.

I have to look up & test doskey s'more, as I don't even remember if I ever knew about it, even as I started with the AT in the early days where I had Peter Norton edit my debug tutorial which I had posted to Usenet somewhere.

While I greatly appreciate that you're following up on my statement to
vallor that the @WSL solution seemed elegant to me (in its own way), I
agree that the doskey solution is likewise elegant, in its own way too.

We're all working together to improve the native inclusion of linux
commands, particularly for the case of running commonly found adb examples.

adb shell dumpsys battery | grep level

level: 95

adb shell pm list packages | sed "s/package://g" | grep filemanager

za.kilowatch.ultimatefilemanager
...
C:\> adb shell pm list packages | tr "." "-" | grep filemanager
package:za-kilowatch-ultimatefilemanager

Where most seem to be working well now, save for that darn awk.

adb shell "dumpsys battery | awk '/level:/ {print \"Battery Level:\", $2 \"%\"}'"

Battery Level: 94%

Most of what I'm learning is by empirical testing, where I'm not 'xactly
sure if the doskey macro works inside a batch file as described though.

Apparently doskey macros are expanded for interactive command-line
input, but a batch file apparently doesn't invoke them when it encounters:
... grep ...
So putting:
doskey grep=wsl grep $*
at the top of the batch file might not actually make the subsequent grep commands use that macro. I'm not sure about that, so it needs testing
as, for a batch file at least, wsl grep might still be necessary.

Your astute point about my grep.cmd wrapper is correct, though.

If a batch file invokes another batch file, it needs call if execution
is to return to the original batch file:
call grep -i gsf
So in a batch file, wsl grep -i gsf is indeed simpler.

But, I'm going to delete the grep.cmd since Paul's suggestion of the
Microsoft Rust CoreUtils has replaced WSL with a native implementation.

For the original interactive use case, however, the doskey solution is
quite elegant, since it avoids creating a wrapper file. The tradeoff is
that the macro has to be established for each CMD session.

For grep, the Microsoft CoreUtils solves that problem quite nicely.
winget install Microsoft.Coreutils
So neither WSL nor a grep.cmd wrapper nor a doskey macro is needed
for grep.

For now, I'm keeping WSL for sed but, unfortunately, awk is a PITA.

Thanks for pushing the doskey idea further as these discussions
help kick the can forward so that everyone can use Linux adb examples
simply by copying them and pasting without needing to translate.
--
Helpful suggestions from people are why Usenet still remains invaluable.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia wrote:

Where most seem to be working well now, save for that darn awk.

adb shell "dumpsys battery | awk '/level:/ {print \"Battery Level:\", $2 \"%\"}'"

Battery Level: 94%

UPDATE

Running this inside quotes directly on the adb shell worked fine because
it was executed entirely inside Android's Linux environment:

adb shell "dumpsys battery | awk '/level:/ {print \"Battery Level:\", $2 \"%\"}'"

Battery Level: 94%

But it had failed when running inside the Windows command line.

adb shell dumpsys battery | awk '/level:/ {print \"Battery Level:\", $2 \"%\"}'

awk: cmd. line:1: /level:/ {print \"Battery Level:\", $2 \"%\"}
awk: cmd. line:1: ^ backslash not last character on line

This is apparently due to quirks in how Windows cmd.exe handles syntax compared to how Linux bash handles that same syntax.

1. Single quotes work fine in Linux, but not in Windows
(so we have to use double quotes instead)
2. Unescaped dollar signs work fine in Linux, but not in Windows
(so we have to escape the dollar signs instead)
3. Linux adb outputs LF (\n) while Windows adb outputs CRLF (\r\n)
(so we have to pipe it to a translate to clean up line endings)

With those three changes, the wsl awk example now works:

adb shell dumpsys battery | wsl tr -d '\r' | wsl awk "/level:/ {print \"Battery Level:\", \$2 \"%\"}"

Which, using MS CoreUtils tr & awk.cmd from this PSA, becomes...

type awk.cmd

@wsl awk %*

adb shell dumpsys battery | tr -d '\r' | awk "/level:/ {print \"Battery Level:\", \$2 \"%\"}"

Battery Level: 92%

As Lawrence and Carlos noted early on, running adb linux commands in
Windows mixes three distinct environments which turns a simple text
pipeline into a miniature diplomatic translation layer because each
system speaks a completely different dialect of shell rules,
quoting conventions, and line endings.

Luckily, the most common adb examples are simpler, so they work better.

adb shell dumpsys battery | grep level

level: 95

adb shell pm list packages | sed "s/package://g" | grep filemanager

za.kilowatch.ultimatefilemanager
...
C:\> adb shell pm list packages | tr "." "-" | grep filemanager
package:za-kilowatch-ultimatefilemanager
--
Android, Windows & Linux walk into a bar to discuss their differences.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Frank Slootweg wrote:

The goal of this PSA is to bridge Windows with Linux so that common
adb examples found on the Internet can be pasted, verbatim, into the CLI. >>

I think, the correct solution is, to install Linux in a virtual
machine. On your next PC install Linux as main OS and Windows in
a virtual machine. And then, in any further PC, you only need Linux.

He mentioned WSL and Ubuntu, so (AFAICT) he already has "Linux in a
virtual machine".

Whether or not he wants/needs the subsequent steps you describe, is
another matter. AFAICT/AFAIK, he needs/uses Windows more than Linux.

These are all good suggestions, as the solution to the problem is what
matters, although I admit, I've been burned many times by a Linux VM.

I don't know if I have too little experience with the Linux VM.
Or too much.

The problem I've experienced in the past is getting OUT of the VM.
It has to talk to the hardware.

However, it has been a long time since I gave up on VMs talking to devices. Have they improved on that huge interoperability problem yet?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Fri, 8/28/2026 12:25 PM, Maria Sophia wrote:

Maria Sophia wrote:

Then we need to add coreutils to the Windows path

setx PATH "%PATH%;C:\Program Files\coreutils"

SUCCESS: Specified value was saved.

WARNING!

Drat. That was a mistake!
C:\> echo %PATH%
Reports coreutils, then stuff, the same stuff, and coreutils again

That setx method was the wrong method, but worse, it wasn't even needed!

Since the purpose of this thread is to be a public service announcement to help others run Linux commands like "grep" on the CLI, notethat the setx above duplicated the path, and worse, the winget of coreutils added the coreutils to the BEGINNING of the path, so, the end result was:
a. CoreUtils was in the beginning of the path
b. Then the old path was duplicated
c. And CoreUtils was added to the end of the path

So, the main advice here is to know that CoreUtils takes care of the path.

What comes now in this article is simply how to fix it if you did it.
1. Back up the path
reg export HKCU\Environment "%USERPROFILE%\path-backup.reg" /y

2. De-duplicate the user path but still preserve the original order
powershell -NoProfile -Command "$u=[Environment]::GetEnvironmentVariable('Path','User') -split ';' | ? {$_}; $m=[Environment]::GetEnvironmentVariable('Path','Machine') -split ';' | ? {$_}; $u=$u | ? {$_ -notin $m} | Select-Object -Unique; [Environment]::SetEnvironmentVariable('Path',($u -join ';'),'User')"

3. Remove the coreutils that was added at the end of the path
powershell -NoProfile -Command "$p=[Environment]::GetEnvironmentVariable('Path','User') -split ';' | ? { $_ -and $_ -ne 'C:\Program Files\coreutils' }; [Environment]::SetEnvironmentVariable('Path',($p -join ';'),'User')"

4. Check the path
echo %PATH%

In summary, when you install the Microsoft CoreUtils, it appends the coreutils to the path for you so you don't have to do it yourself.

There are also things which can be loaded, which are not in the path.
Having a path fixation, is not entirely an answer. The Metro.App could
quite well have a couple designated storage areas. And there could be
registry recording of "viable" executables. The permissions on Metro.App storage, do not allow easy examination, but you can use nfi.exe to list
stuff like that. Some things that execute on Windows, are being located
via registry location storage.

For a lot of people, the contents of their PATH will be a puzzle for them,
as it's not an area people look at much any more. And since there are
so many install methods, you really cannot be sure that a given installer
does the right things for the job. A WinGet of a GREP package, the gnuwin32 one,
does that work ? You'd have to test whether the installation process
even proceeded in a logical manner. It's different when you know a developer provided an installer for the job of doing that.

Curation of facilities on Windows has degraded to the level of poop.
The poor bastard working on the loader. I don't even know if there
is an authoritative and logically written description of how everything
loads, or what gubbins are needed to load stuff. If this is evolution,
its knuckles are dragging on the ground again. Throwing an undocumented (repositories...) WinGet into the mix, that's just a sloppy icing
for our poop cake.

So while it's great to write lines of Powershell to do this and that,
this is not "teaching a man to fish". This is "giving him a fish".
We don't have a reliable treatise useful for teaching a man to fish.
If I asked an LLM-Ai to do this, it is quite possible it would
forget a few methods. And as you "have to know the answer" to trust
an LLM-AI screed, there's no guarantee of good coverage of the topic.

I would hope Microsoft keeps internal documents on the topic, but
who really knows. Otherwise, how would a new employee become familiar
with the labyrinth. Asking the person in the cubicle next to you,
is not considered a good usage of their time. And asking Raymond,
Raymond is busy. He's already shoving shit that should have been
shoveled years ago.

This is one of the differences at Apple. Historically, they had
"Inside Macintosh". The format and presentation, is preserved
in TN (Technical Notes). Some of the notes are fantastically good.
I wrote a partition manager once for my Mac disk, and I could
do that using a *single* TN, didn't have to read anything else.
(This was after gparted impressed me by utterly destroying the partition table.)
When they choose to document something, it's not a half hearted
effort on their part. The efforts are usually "better than Wikipedia"
level of technical notes. The way someone might explain a thing
to you in a USENET post. Whereas the Microsoft documentation
is unimaginative "the boss is beating me with a stick to write
this description" flavored documentation, the best kind of
documentation when you really needed charitably written material.

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

UPDATE

I think we're solved the AWK problem, thanks to the help from many others.

adb shell pm list packages | awk -F: "{print \$2}" | grep shiz

moe.shizuku.privileged.api

adb shell pm list packages | wsl awk "{sub(/^package:/, \"\"); print}" | grep shizu

moe.shizuku.privileged.api

adb shell dumpsys battery | wsl tr -d '\r' | wsl awk "/level:/ {print \"Battery Level:\", \$2 \"%\"}"

Battery Level: 93%

Previously we had to pass the entire instruction string via adb shell
to bypass local Windows parsing, letting Android's built-in toybox/busybox awk handle the script natively without any WSL or .cmd wrapper gymnastics.
C:\> adb shell "dumpsys battery | awk '/level:/ {print \"Battery Level:\", $2 \"%\"}'"

But now, with the awk.cmd set up, we can run these WSL awk examples.

type awk.cmd

@wsl awk %*

adb shell pm list packages | awk -F: "{print \$2}"

moe.shizuku.privileged.api

adb shell pm list packages | awk "{sub(/^package:/, \"\"); print}"

moe.shizuku.privileged.api

adb shell dumpsys battery | tr -d '\r' | awk "/level:/ {print \"Battery Level:\", \$2 \"%\"}"

Battery Level: 92%

Overall, we've had success based on the excellent recommendations from Paul (who was instrumental in adding the Rust CoreUtils to the discussion),
but also the helpful recommendations from Herbert & Lawrence and the
useful criticisms brought up by Frank, Carlos & vallor to flesh out ideas.

Given the recent release of Microsoft Rust Utils, it's useful to note that most of the WSL commands can be considered moot given we now have native implementations which are already included in the path for 75 utilities.

Running this command garners, AFAICT, most of what this PSA is about.

winget install Microsoft.Coreutils

Since every post should add value, here's a catalogue of what it added.

File & Directory Operations:
cp, mv, rm, mkdir, rmdir, ls, ln, link, unlink, touch, pwd, basename,
dirname, realpath, readlink

Text Processing & Display:
cat, tac, head, tail, echo, printf, tee, wc, grep, sort, uniq, cut,
paste, join, comm, fold, fmt, tr, expand, unexpand, split, csplit, nl,
od, seq, shuf, ptx

Checksums & Formatting:
md5sum, sha1sum, sha224sum, sha256sum, sha384sum, sha512sum, b2sum,
cksum, sum, numfmt, factor, expr

Environment & System Info:
arch, nproc, uname, hostname, uptime, date, sleep, true, false, yes,
test, env, printenv, whoami, coreutils-manager

File Management & Attributes:
df, du, stat, truncate, mktemp, pathchk, install, find, xargs

Notably missing are apparently these, which WSL2CLI.bat might be used
to add as per the original PSA post, but only after testing them.

Text & Pattern Processing:
awk, sed

Archiving & Compression:
tar, gzip, gunzip, bzip2, zip, unzip

File Comparison & Patching:
diff, patch, cmp

Pagination:
less, more

Networking:
curl, wget, netcat, ssh

Shells & Scripting:
bash, sh

Here are some working examples of what we've been able to accomplish.
First, elevate the shell privileges and then check elevated-shell status

adb shell sh /storage/emulated/0/Android/data/moe.shizuku.privileged.api/start.sh
adb shell ps -A | grep -i shizuku

u0_a828 20618 901 6490828 151572 0 0 S moe.shizuku.privileged.api
shell 20817 1 5139096 88596 SyS_epoll_wait 0 S shizuku_server

Sort the shizuku processes by order of occurrence

adb shell ps -A | grep -i shizuku | sort -nk2

u0_a828 20618 901 6490828 148484 0 0 S moe.shizuku.privileged.api
shell 20817 1 5139096 88320 SyS_epoll_wait 0 S shizuku_server

Filter package names for shizuku

adb shell pm list packages | cut -d: -f2 | grep shiz

moe.shizuku.privileged.api

Count total packages that the user installed themslves

adb shell pm list packages | wc -l

1021

Check the battery level

adb shell dumpsys battery | awk '/level:/ {print "Battery Level:", $2 "%"}' | tr -d '\r'

Battery Level: 92%

Retrieve wi-fi ip addres

C:\app\editor\android\scrcpy> adb shell ip addr show wlan0 | awk '/inet / {print "IP Address:", $2}'

IP Address: 192.168.1.4/24
--
Usenet allows helpful experts around the world combine their experiences.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence D'Oliveiro wrote:

I, for one, always thought Linux, being free and rather capable,
would outcompete Windows, but alas, there's power to corporate
MSOffice that is undeniably sticky, to the point that Linux is
mostly servers, not desktops.

Microsoft seems to be moving away from Microsoft Office towards
Microsoft 365. And the latter lists Linux as an officially-supported platform.

Oh wow. For decades, I wondered why Linux didn't kill Windows, where, over
the years, I had to conclude that the MS Office suite was sticky stuff in corporate environs, and, seemingly just as web like in home computing.

To me that was surprising, but part of the reason I guess was Microsoft
Windows was supported and freely upgradeable for quite a long time too.

While I use any MS Office that I still have (usually 2007, 2010 or 2016), I guess most people "upgrade" to the latest version, which is subscription nowadays.

But looking up the Linux implementation, apparently Microsoft 365 relies heavily on a browser-based delivery model (and Progressive Web Apps) rather than a native desktop application for Linux.

Apparently, while Microsoft officially supports accessing M365 via web
browsers on Linux, its not the full-fledged native binaries that
corporations tend to use (from what I gathered looking it up).

But...

If Linux runs MS Office "stuff" as well as Windows/macOS, at that point, there's little reason (other than inertia) to stick with Microsoft (IMHO).

What else is keeping the general populace from using Linux over Windows?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Fri, 28 Aug 2026 15:27:32 -0600, Maria Sophia wrote:

For decades, I wondered why Linux didn't kill Windows, where, over
the years, I had to conclude that the MS Office suite was sticky
stuff in corporate environs, and, seemingly just as web like in home computing.

Linux has taken over every market outside the desktop where Windows
has tried to go: mobile (Windows Phone, Windows RT), living-room
(Windows Media Center), home server (Windows Home Server), corporate
(Windows Server), supercomputer (Windows Server HPC) -- all those
Microsoft products were killed by Linux.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence DrCOOliveiro wrote on 8/28/2026 5:26 PM:

On Fri, 28 Aug 2026 15:27:32 -0600, Maria Sophia wrote:

For decades, I wondered why Linux didn't kill Windows, where, over
the years, I had to conclude that the MS Office suite was sticky
stuff in corporate environs, and, seemingly just as web like in home
computing.

Linux has taken over every market outside the desktop where Windows
has tried to go: mobile (Windows Phone, Windows RT), living-room
(Windows Media Center), home server (Windows Home Server), corporate
(Windows Server), supercomputer (Windows Server HPC) -- all those
Microsoft products were killed by Linux.

Indeed. I am amazed that there are still 7 people left who claim to run microsoft windows. I think they are all running linux and lying about it.

Why do they do this?




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Frank Slootweg wrote:

If others wonder why I responded to "Frank Slootweg" the way I did, they
first need to know he's a common troll who has infested Usenet for decades.

I hope you like the pie and egg.

Hi Frank,

Usenet, to me, is water under the bridge.
a. Treat me the way you want to be treated
b. And I respond, in kind

I have no qualms whatsoever for atoning for my sins as this isn't a game of oneupmanship, but a sincere kind-hearted quest for solving hard problems.

So again, I easily and humbly and publicly apologize to you for not appreciating that you were first who suggested that grep was, indeed,
inside the coreutils, which is critical since grep is very important.

That one revelation changes this entire public service announcement,
because all we're left with fixing are the commands NOT in the coreutils.

The sed seems to work, but the awk is a PITA due to the differences in how Android, Windows & Linux handle single quotes, dollar signs & line feeds.

Overall, this PSA should have been about Microsoft CoreUtils & not WSL.
Since every post should add value, here's a catalogue of what it added.

File & Directory Operations:
cp, mv, rm, mkdir, rmdir, ls, ln, link, unlink, touch, pwd, basename,
dirname, realpath, readlink

Text Processing & Display:
cat, tac, head, tail, echo, printf, tee, wc, grep, sort, uniq, cut,
paste, join, comm, fold, fmt, tr, expand, unexpand, split, csplit, nl,
od, seq, shuf, ptx

Checksums & Formatting:
md5sum, sha1sum, sha224sum, sha256sum, sha384sum, sha512sum, b2sum,
cksum, sum, numfmt, factor, expr

Environment & System Info:
arch, nproc, uname, hostname, uptime, date, sleep, true, false, yes,
test, env, printenv, whoami, coreutils-manager

File Management & Attributes:
df, du, stat, truncate, mktemp, pathchk, install, find, xargs

Notably missing are apparently these, which WSL2CLI.bat might be used
to add as per the original PSA post, but only after testing them.

Text & Pattern Processing:
awk, sed

Archiving & Compression:
tar, gzip, gunzip, bzip2, zip, unzip

File Comparison & Patching:
diff, patch, cmp

Pagination:
less, more

Networking:
curl, wget, netcat, ssh

Shells & Scripting:
bash, sh

Here are some working examples of what we've been able to accomplish.
First, elevate the shell privileges and then check elevated-shell status

adb shell sh /storage/emulated/0/Android/data/moe.shizuku.privileged.api/start.sh
adb shell ps -A | grep -i shizuku

u0_a828 20618 901 6490828 151572 0 0 S moe.shizuku.privileged.api
shell 20817 1 5139096 88596 SyS_epoll_wait 0 S shizuku_server

Sort the shizuku processes by order of occurrence

adb shell ps -A | grep -i shizuku | sort -nk2

u0_a828 20618 901 6490828 148484 0 0 S moe.shizuku.privileged.api
shell 20817 1 5139096 88320 SyS_epoll_wait 0 S shizuku_server

Filter package names for shizuku

adb shell pm list packages | cut -d: -f2 | grep shiz

moe.shizuku.privileged.api

Count total packages that the user installed themslves

adb shell pm list packages | wc -l

1021

Check the battery level

adb shell dumpsys battery | awk '/level:/ {print "Battery Level:", $2 "%"}' | tr -d '\r'

Battery Level: 92%

Retrieve wi-fi ip addres

C:\app\editor\android\scrcpy> adb shell ip addr show wlan0 | awk '/inet / {print "IP Address:", $2}'

IP Address: 192.168.1.4/24
--
On Usenet, we pool our knowledge so everyone's a little smarter.




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On 2026-08-28 21:37, Paul wrote:

On Fri, 8/28/2026 12:25 PM, Maria Sophia wrote:

Maria Sophia wrote:

This is one of the differences at Apple. Historically, they had
"Inside Macintosh". The format and presentation, is preserved
in TN (Technical Notes). Some of the notes are fantastically good.
I wrote a partition manager once for my Mac disk, and I could
do that using a *single* TN, didn't have to read anything else.
(This was after gparted impressed me by utterly destroying the partition table.)
When they choose to document something, it's not a half hearted
effort on their part. The efforts are usually "better than Wikipedia"
level of technical notes. The way someone might explain a thing
to you in a USENET post. Whereas the Microsoft documentation
is unimaginative "the boss is beating me with a stick to write
this description" flavored documentation, the best kind of
documentation when you really needed charitably written material.

I bought a book named something like "undocumented windows" long ago.
That was w3.11, I think. Also the Programmers Reference, the User Guide
and Reference for MsDos 5...
--
Cheers,
Carlos E.R.
ESEfc-Efc+, EUEfc-Efc|.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Hank Rogers <Hank@nospam.invalid> wrote:

Lawrence D?Oliveiro wrote on 8/28/2026 5:26 PM:

On Fri, 28 Aug 2026 15:27:32 -0600, Maria Sophia wrote:

For decades, I wondered why Linux didn't kill Windows, where, over
the years, I had to conclude that the MS Office suite was sticky
stuff in corporate environs, and, seemingly just as web like in home
computing.

Linux has taken over every market outside the desktop where Windows
has tried to go: mobile (Windows Phone, Windows RT), living-room
(Windows Media Center), home server (Windows Home Server), corporate (Windows Server), supercomputer (Windows Server HPC) -- all those
Microsoft products were killed by Linux.

Indeed. I am amazed that there are still 7 people left who claim to run microsoft windows. I think they are all running linux and lying about it.

Why do they do this?

Exactly! As is clear from my 'User-Agent:' header, I'm one of those
liars.

I try to fob people off by using sed(1) (Can I be *more transparent!?)
to insert lame attempts like "CYGWIN", "NT", "WOW", etc. but of course
nobody is really falling for *that* one.

BTW, I didn't know that apparantly Android is Linux, but macOS isn't Unix/UNIX. Never too old to learn.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Carlos E. R. wrote:

I bought a book named something like "undocumented windows" long ago.
That was w3.11, I think. Also the Programmers Reference, the User Guide
and Reference for MsDos 5...

The good news is we've basically documented every operating system, on
Usenet, over the years, if only we could get an archive to hang around.

I'm not quite sure which of these still works though, nor where.
<https://www.planetusenet.com/groups/alt.os.linux> r/w, not in the UK
<https://csiph.com/group/alt.os.linux> r/w
<https://tinyurl.com/pug-alt.os.linux>
<https://i2pn2.pugleaf.net/groups/alt.os.linux>
<https://newsgrouper.org/alt.os.linux> <== still works as of 6/2026
<https://alt.os.linux.narkive.com/>
<https://groups.google.com/forum/#!forum/alt.os.linux
<https://groups.google.com/g/alt.os.linux>
<https://www.novabbs.com/tech/thread.php?group=alt.os.linux>

What we've recently documented in this public service announcement though,
is how to add *native* linux commands to the average Windows desktop setup.

We can add these to the Windows path simply by running a single command!

winget install Microsoft.Coreutils

arch, nproc, uname, hostname, uptime, date, sleep, true, false, yes,
cat, tac, head, tail, echo, printf, tee, wc, grep, sort, uniq, cut,
cksum, sum, numfmt, factor, expr
cp, mv, rm, mkdir, rmdir, ls, ln, link, unlink, touch, pwd, basename,
df, du, stat, truncate, mktemp, pathchk, install, find, xargs
dirname, realpath, readlink
md5sum, sha1sum, sha224sum, sha256sum, sha384sum, sha512sum, b2sum,
od, seq, shuf, ptx
paste, join, comm, fold, fmt, tr, expand, unexpand, split, csplit, nl,
test, env, printenv, whoami, coreutils-manager

Notably missing from coreutils are these, which WSL2CLI.bat might be used
to add as per the original PSA post, but only after testing them.

awk, sed
bash, sh
curl, wget, netcat, ssh
diff, patch, cmp
less, more
tar, gzip, gunzip, bzip2, zip, unzip

So far, this is likely the easiest and safest way possible to instantly add basic linux commands to Windows, but other solutions certainly do exist.
--
Here on Usenet each of us have decades of experience setting up devices.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia wrote:

Yeah. I realized that. Even with WSL & CoreUtils.
Only the simplest of awk commands worked.

It's too bad the MS Rust CoreUtils don't have awk & sed though...

However, since this PSA is meant to kick the ball forward, I should point
out that "wsl awk" worked just fine. It did what it was supposed to do.

Perfectly.

The problem was Windows adb added things that we have to sed out first.

Working examples:

type awk.cmd

@wsl awk %*

adb shell dumpsys battery | tr -d '\r' | awk "/level:/ {print \"Battery Level:\", \$2 \"%\"}"

Battery Level: 92%

adb shell ip addr show wlan0 | awk '/inet / {print "IP Address:", $2}'

IP Address: 192.168.1.4/24

In summary, these two commands instantly add most of the basic Linux to Windows.

winget install Microsoft-Coreutils
wsl2cli.bat (assuming WSL is already installed)

--
I strive to add technical value, if possible, with every post to Usenet.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Sat, 29 Aug 2026 16:40:32 -0600, Maria Sophia wrote:

It's too bad the MS Rust CoreUtils don't have awk & sed though...

perl >> awk

sed ... I suppose it has its uses ...
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence DoOliveiro wrote:

It's too bad the MS Rust CoreUtils don't have awk & sed though...

perl >> awk

sed ... I suppose it has its uses ...

Hi Lawrence,

In interpreting your sagacious comment above, I have to openly admit that
I'm not a coder, in that I've programmed extensively, but in IBM360
Assembly & JCL, COBOL, Fortan IV, PL/1, etc., which, as you can tell, dates
me back to the 1960's and 1970s' as the last time I did serious coding.

Perl, by way of contrast, dating only to 1987, is a newcomer, to me.
So I've never actually used Perl.

However, if someone invests the energy to make a suggestion on Usenet,
I likewise invest energy in at least attempting to UNDERSTNAD what they are trying to impart.

Given your "perl >> awk" suggestion above, noting that every post to Usenet should, by design, kick the ball forward, I tested out that premise below.

Looking up the advantages of Perl, apparently Perl users traditionally view sed as limited because Perl can do everything sed can do (via regular expression substitutions like s/find/replace/), but with the added power
of a full programming language.

So let's test it out...

perl

'perl' is not recognized as an internal or external command,
operable program or batch file.

winget install StrawberryPerl

Found Strawberry Perl [StrawberryPerl.StrawberryPerl] Version 5.42.2.1
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to,
third-party packages. Downloading
https://github.com/StrawberryPerl/Perl-Dist-Strawberry/releases/download/SP_54221_64bit/strawberry-perl-5.42.2.1-64bit.msi
200 MB / 200 MB
Successfully verified installer hash
Starting package install...
Successfully verified installer hash
Starting package install...
Successfully installed

where perl

C:\Strawberry\perl\bin\perl.exe
Note that this is an ungodly dumb location for the default to be.
Looking up why such an idiotic location is the default, ironically
indicates that the Windows perl is incapable of handling spaces
in the path correctly (e.g., "Program<space>Files"). </Irony>

Still, in Windows cmd.exe, single quotes (') do NOT protect variables
the way they do in Linux, so we still have the same horrors to overcome.

WSL awk:

adb shell dumpsys battery | tr -d '\r' | awk "/level:/ {print \"Battery Level:\", \$2 \"%\"}"

Battery Level: 92%
Strawberry Perl:
We have to bypass cmd.exe's habit of mishandling single quotes.

adb shell dumpsys battery | perl -ne "s/\r//; if (/level:\s*(\d+)/) { print 'Battery Level: $1%\n' }"

Battery Level: $1%\n
We also have to bypass cmd.exe's swallowing backslashes/newlines (\n)
and we have to also protect variables from cmd.exe expansion.

adb shell dumpsys battery | perl -ne "s/\r//; if (/level:\s*(\d+)/) { print 'Battery Level: ' . $1 . '%%\n'; }"

Battery Level: 92%%\n
Resulting in a working example using Perl flags (-nl) and qq{} interpolation,
but the percent sign must be doubled to avoid Perl misinterpreting it as a hash.

adb shell dumpsys battery | perl -nl -e "if (/level:\s*(\d+)/) { print qq{Battery Level: $1%%}; }"

Battery Level: 92%%
So we use Perl's hex ASCII code (\x25) to get rid of the duplicated
percent sign to ensure a clean terminal exit.

adb shell dumpsys battery | perl -nl -e "if (/level:\s*(\d+)/) { print qq{Battery Level: $1\x25}; }"

Battery Level: 92%

WSL awk:

adb shell ip addr show wlan0 | awk '/inet / {print "IP Address:", $2}'

IP Address: 192.168.1.4/24
Strawberry Perl:
We have the same problem of mishandling of quotes and newlines.

adb shell ip addr show wlan0 | perl -ne "s/\r//; if (/inet\s+(\S+)/) { print 'IP Address: $1\n' }"

IP Address: $1\n

adb shell ip addr show wlan0 | perl -nl -e "if (/inet\s+(\S+)/) { print qq{IP Address: $1}; }"

IP Address: 192.168.1.4/24

This is apparently due to quirks in how Windows cmd.exe handles syntax compared to how Linux bash handles that same syntax.

1. Single quotes work fine in Linux, but not in Windows
(so we have to use double quotes instead)
2. Unescaped dollar signs work fine in Linux, but not in Windows
(so we have to escape the dollar signs instead)
3. Linux adb outputs LF (\n) while Windows adb outputs CRLF (\r\n)
(so we have to pipe it to a translate to clean up line endings)

But once we figure those issues out, perl works as well as awk.

adb shell getprop | tr -d '\r' | awk -F': ' '/ro\.product\.model/ {gsub(/[\[\]]/, "", $2); print "Device Model:", $2}'

Device Model: SM-A326U

adb shell getprop | perl -nl -e "if (/\[ro\.product\.model\]:\s*\[(.*?)\]/) { print qq{Device Model: $1}; }"

Device Model: SM-A326U

The question, I guess, is which is the least worst way of doing it?
--
Every fixed example is someone paying forward a hard-learned lesson.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Sat, 29 Aug 2026 23:05:42 -0600, Maria Sophia wrote:

This is apparently due to quirks in how Windows cmd.exe handles
syntax compared to how Linux bash handles that same syntax.

Remember what I said earlier about fundamental limitations in the way
Windows handles the command line?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Sun, 8/30/2026 2:56 AM, Lawrence DrCOOliveiro wrote:

On Sat, 29 Aug 2026 23:05:42 -0600, Maria Sophia wrote:

This is apparently due to quirks in how Windows cmd.exe handles
syntax compared to how Linux bash handles that same syntax.

Remember what I said earlier about fundamental limitations in the way
Windows handles the command line?

I bet you can find better ways to do it.

In gawk, you can put a couple lines in a BEGIN {} clause
to handle line endings in and out. When you take
a script from Windows to Linux, you can add that to your
script to compensate for line endings.

BEGIN {
RS="\r\n";
ORS="\n";
}

These inline scripts, don't have to be inline.
You can shield them in their own files. Then the
Perl or AWK follow their own rules on quoting or whatever.
Sometimes, it's even easier to read the code and
make sense of it, if the code is indented and so on.

I don't normally do AWK one-liners. I like to put them
in files, for searching them later. I can look for file
extension .awk and Agent Ransack content search on RS,
to find examples of how to use RS.

Just about every OS, has pitiful examples of escape sequences,
and how you can "spend half a morning" figuring it out. It's
better to just reduce the mental load by putting things in boxes.

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia, 2026-08-27 04:08:

PSA: How to add WSL grep to the Windows command-line PATH

This is an Android:Windows cross-platform problem that I run into every
day because most adb examples we find on the net use grep (not findstr).

It's a PITA to constantly convert adb examples using grep to findstr.

So this approach below is what I just decided to finally do after getting tired of converting adb|grep examples found on the net to findstr syntax.

I recognize there are many ways to add "grep" to the Windows path.
But, since I already had WSL installed for other reasons, it bothered me
that I couldn't just call the Ubuntu grep from the Windows command line.

What good is WSL if you can't use it when you need it?

Well - I switched to Linux completely a while ago since I couldn't stand
using Windows 11 any longer. I did never regret it. Currently using
Kubuntu 26.04 with KDE 6.6 and I don't miss anything at all.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Sun, 30 Aug 2026 12:58:40 +0200
Arno Welzel <usenet@arnowelzel.de> wrote:

Maria Sophia, 2026-08-27 04:08:

PSA: How to add WSL grep to the Windows command-line PATH

This is an Android:Windows cross-platform problem that I run into every day because most adb examples we find on the net use grep (not findstr).

It's a PITA to constantly convert adb examples using grep to findstr.

So this approach below is what I just decided to finally do after getting tired of converting adb|grep examples found on the net to findstr syntax.

I recognize there are many ways to add "grep" to the Windows path.
But, since I already had WSL installed for other reasons, it bothered me that I couldn't just call the Ubuntu grep from the Windows command line.

What good is WSL if you can't use it when you need it?

Well - I switched to Linux completely a while ago since I couldn't stand using Windows 11 any longer. I did never regret it. Currently using
Kubuntu 26.04 with KDE 6.6 and I don't miss anything at all.

Clearly you miss the xposts.

--
Arno Welzel
https://arnowelzel.de

--
Bah, and indeed Humbug.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Arno Welzel wrote:

What good is WSL if you can't use it when you need it?

Well - I switched to Linux completely a while ago since I couldn't stand using Windows 11 any longer. I did never regret it. Currently using
Kubuntu 26.04 with KDE 6.6 and I don't miss anything at all.

It used to be there were two things Linux does that Windows can't hope to
do, one of which is the command line and the other of which is MS Office.

This entire thread is about the power of the command line, so nobody doubts Linux superiority there, but I think someone said MS Office is catching up.
--
Usenet is where people with vast knowledge converge to discuss ideas.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Paul wrote:

Just about every OS, has pitiful examples of escape sequences,
and how you can "spend half a morning" figuring it out. It's
better to just reduce the mental load by putting things in boxes.

To help move the ball forward, what I'm compiling, which may take some
time, is a list of *useful adb commands", many of which may use awk.

Then others can just paste the commands, without having to worry
about line feeds, or escaping dollar signs or single vs double quotes.
--
Every working example is someone paying forward a hard-learned lesson.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Sun, 30 Aug 2026 05:26:13 -0400, Paul wrote:

On Sun, 8/30/2026 2:56 AM, Lawrence DrCOOliveiro wrote:

On Sat, 29 Aug 2026 23:05:42 -0600, Maria Sophia wrote:

This is apparently due to quirks in how Windows cmd.exe handles
syntax compared to how Linux bash handles that same syntax.

Remember what I said earlier about fundamental limitations in the
way Windows handles the command line?

I bet you can find better ways to do it.

On Windows, you can only do this by avoiding putting things on the
command line altogether:

These inline scripts, don't have to be inline. You can shield them
in their own files. Then the Perl or AWK follow their own rules on
quoting or whatever.

However:

Just about every OS, has pitiful examples of escape sequences, and
how you can "spend half a morning" figuring it out.

Some are more pitiful than others.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Just install Microsoft coreutils.
https://github.com/microsoft/coreutils

It's not worth downgrading my useful WSL2 to WSL1 just to avoid
installing Microsoft coreutils.
--
Brian Gregory (in England).
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Brian Gregory wrote:

Just install Microsoft coreutils.
https://github.com/microsoft/coreutils

It's not worth downgrading my useful WSL2 to WSL1 just to avoid
installing Microsoft coreutils.

Hi Brian,

CoreUtils alone, does *not* solve the problem.
But CoreUtils goes a long way...

So we need *more* than just coreutils...
But we've solved that problem in this thread.

And, I'm not sure why you said wsl2 needs to be downgraded to wsl1.
Nobody even tested wsl2 so I certainly never said or implied that.

But the good news is a *combination* of CoreUtils + WSL saves the day!

So everyone wins by the combined kind-hearted effort to add the most
important Linux commands to the Windows command line in two commands.
1. C:\> winget install Microsoft.Coreutils
2. C:\> wsl2cli.bat (included in this thread)

Voila!
That solves the problem for all the common Linux commands.

Here's what you missed...
a. I run a lot of adb examples on Windows found on the net
b. Most pipe the adb output to a grep or sed or awk or whatever
c. I got tired of porting them to Windows/powershell
d. And long ago I became sick of VMs (which don't handle hardware)
e. Even longer ago I gave up on Cygwin-like abominations
f. So I came up with this efficient idea of @WSL stubs
g. Which worked so well that I wanted others to benefit from the idea
h. So I wrote up this public service announcement to help others
i. And, to further help, I wrote up a wsl2cli.bat script to help others
j. Yet Paul wrote back what you wrote, which was use coreUtils instead
k. Which I did, and which work for most of the important commands
l. But which don't even have awk or sed, so not for all the commands

In the end, what you need is a *combination* of the coreutils & wsl.
--
Usenet is where kind people daily gather to voluntarily help others.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Frank Slootweg wrote:

And how is your proposed solution less "convoluted" than a 1-line bridge?

"How many of these do you have to write before it becomes simpler just
to run a Linux system?"

The solution we came up with, together, is arguably elegantly brilliant.
It's just 2 commands, run once, & then forever, the CLI can pipe to Linux.

winget install Microsoft.Coreutils (gains most of the Linux commands)
wsl2cli.bat (adds awk & sed, in particular, to the path)

It's just not the solution you came up with (i.e., Cygwin) as we've been
there, and done that, and ditched it, oh, maybe twenty five years ago.

There is nothing wrong with the Cygwin abomination if you already have it running, just as a Linux inside a VM is fine, if it talks to your phone.

But...

The stated problem set was that adb examples on the net abound but they
contain pipes to Linux commands such as grep, awk, sed, tr, etc.

If someone already has WSL{1,2} installed, the original PSA solution was a one-line command, wsl2cli.bat, which adds WSL commands to the Windows CLI.

wsl2cli.bat

After that public service announcement was written, Paul informed us all of
the very recent Microsoft Rust CoreUtils, which works for things like grep.

winget install Microsoft.Coreutils

As you are aware, that puts many of the Linux utils native in the path.

The problem is that awk & sed, in particular, are NOT in the CoreUtils.

So everyone wins by the combined kind-hearted effort to add the most
important Linux commands to the Windows command line in two commands.
1. C:\> winget install Microsoft.Coreutils
2. C:\> wsl2cli.bat (included in this thread)

Voila!
Two simple commands solves the problem for all the common Linux commands.

Does it not?
--
On Usenet, we can pool our knowledge and skills so everyong learns more.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia wrote:

The solution we came up with, together, is arguably elegantly brilliant.
It's just 2 commands, run once, & then forever, the CLI can pipe to Linux.

winget install Microsoft.Coreutils (gains most of the Linux commands)
wsl2cli.bat (adds awk & sed, in particular, to the path)

If there is a more brilliantly elegant solution to the problem, let us know.

However...
I should note that not everyone has WSL{1,2} already installed on Windows.

Yet the whole point of this public service announcement is to help those
who don't yet have the necessary Linux commands in their command-line path.

To that end, for a barren Windows installation, the list of necessary
setup commands increases by 50% from running two setup commands, to three.

1. C:\> winget install Microsoft.Coreutils
2. C:\> wsl --install
3. C:\> wsl2cli.bat

The first command puts most of the Linux commands into the user's path.
The second command installs WSL2/Ubuntu by default (it can be changed).
The third command puts things like awk & sed into the users' path.

Voila!

If anyone has a more brilliantly elegant solution, let us all know!
--
On Usenet, kind hearted people try to help each other all day every day.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence DoOliveiro wrote:

On Thu, 27 Aug 2026 20:33:13 -0600, Maria Sophia wrote:

At least in my experience, that implies that a Linux VM can be an
even worse implementation than Cygwin, but for very different
reasons.

Linux VMs are used heavily in mission-critical deployments.

Hi Lawrence,

In my humble experience, admittedly maybe a decade or more ago, the problem with running operating systems inside of a VM is talking to peripherals.

So I shy away from VMs as I've been burned in the past, even as WSL is a
VM, and I shy away from Cygwin-like solutions, also because I've been had.

Anyway, I think we've elegantly brilliantly solved the problem set nicely.
1. C:\> winget install Microsoft.Coreutils
2. C:\> wsl --install
3. C:\> wsl2cli.bat

That's three commands.
It's ingenious, is it not!

I *love* brilliantly simple elegant solutions to difficult problem sets!
I really do.

That simple sequence adds most of Linux to the Windows command line path.

In fact...
If anyone has a *simpler* more elegant solution than that, let us know!

(I will update the wsl2cli.bat later to remove the CoreUtils duplication.)
--
Sometimes it takes a group of people to come up with the perfect solution.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Sun, 30 Aug 2026 20:53:25 -0600, Maria Sophia wrote:

I should note that not everyone has WSL{1,2} already installed on
Windows.

Surely all those still trying to do serious development on Windows
will have WSL2 or later.

<https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence D?Oliveiro <ldo@nz.invalid> wrote:

On Sun, 30 Aug 2026 20:53:25 -0600, Maria Sophia wrote:

I should note that not everyone has WSL{1,2} already installed on
Windows.

Surely all those still trying to do serious development on Windows
will have WSL2 or later.

<https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>

I liked this bit:

"The lions share of the worlds software development work happens on
Linux, or a Unix-like system like macOS,"

:-)

Also note that this article is not about replacing Windows as a
development platform, but about *adding* a Linux/Unix development
environment to it.

So as we've been saying all along: Linux cannot replace Windows, nor
vice versa.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia <mariasophia@comprehension.com> wrote:

Frank Slootweg wrote:

[...]

It's just not the solution you came up with (i.e., Cygwin) as we've been there, and done that, and ditched it, oh, maybe twenty five years ago.

There is nothing wrong with the Cygwin abomination if you already have it running, just as a Linux inside a VM is fine, if it talks to your phone.

As I said before, Cygwin is way more complete and flexible than both 'Coreutils for Windows' and GnuWin. *Because* it's more complete/
powerful than the other two, it encounters more Windows/Unix
differences, which it has to handle. That's not an "abomination", but
the consequence of its power.

BTW, Lawrence just posted a link to this

'How to set up Windows for software development' <https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>

which says

"Some other tools for developing in Windows are optional, but useful:
...
* MSYS2 (MSYS2.MSYS2): A collection of tools for building Windows
binaries using the GCC compiler. Basically, an alternative to the
Visual Studio build stack based on the Cygwin environment."

So much for "the Cygwin abomination"! :-)

And yes, it *also* mentions 'CoreUtils for Windows'.

[...]
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Frank Slootweg wrote:

Also note that this article is not about replacing Windows as a
development platform, but about *adding* a Linux/Unix development
environment to it.

So as we've been saying all along: Linux cannot replace Windows, nor
vice versa.

I agree with both Lawrence & Frank in interpretation of this article
<https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>

And, like Frank, I note some sentences in particular such as
"Windows Subsystem for Linux (WSL) lets you work seamlessly
with Linux on Windows without the clunk and overhead of a VM."

When I saw that sentence, I checked the date of the article, which
surprised me was recent because it was my understanding WSL2 is inside a VM while WSL1 was not inside a VM (the core difference being native vs
non-native Linux commands).

AFAIK:
WSL 1 used a translation layer. It intercepted Linux system calls
and translated them on-the-fly into Windows NT kernel system calls.

WSL 2 runs a Linux kernel inside a virtual machine powered by Hyper-V.

Inside that VM-that's-not-a-VM, Windows users can run these distros

C:\> wsl --list --online
The following is a list of valid distributions that
can be installed. Install using 'wsl --install -d <Distro>'.
NAME FRIENDLY NAME
Ubuntu Ubuntu
Debian Debian GNU/Linux
kali-linux Kali Linux Rolling
OracleLinux_7_9 Oracle Linux 7.9
OracleLinux_8_10 Oracle Linux 8.10
OracleLinux_9_5 Oracle Linux 9.5
SUSE-Linux-Enterprise-15-SP6 SUSE Linux Enterprise 15 SP6
openSUSE-Tumbleweed openSUSE Tumbleweed

This is all in keeping with the purposefully helpful intent of this public service announcement, which is all about easily using Linux inside the CLI.

It's brilliantly elegant how to add Linux commands to Windows in 3 steps.
1. C:\> winget install Microsoft.Coreutils
2. C:\> wsl --install
3. C:\> wsl2cli.bat

The first command adds most of the Linux commands to the CLI path.
The second command adds the commands, but not to the path.
The third command adds those remaining commands to the path.

Note: I need to make a new version of wsl2cli because we only need to add
to it those commands which don't come with the coreutils, such as awk/sed.
--
Usenet is where people with vast knowledge converge to discuss ideas.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Frank Slootweg wrote:

There is nothing wrong with the Cygwin abomination if you already have it
running, just as a Linux inside a VM is fine, if it talks to your phone.

As I said before, Cygwin is way more complete and flexible than both 'Coreutils for Windows' and GnuWin. *Because* it's more complete/
powerful than the other two, it encounters more Windows/Unix
differences, which it has to handle. That's not an "abomination", but
the consequence of its power.

BTW, Lawrence just posted a link to this

'How to set up Windows for software development' <https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>

which says

"Some other tools for developing in Windows are optional, but useful:
...
* MSYS2 (MSYS2.MSYS2): A collection of tools for building Windows
binaries using the GCC compiler. Basically, an alternative to the
Visual Studio build stack based on the Cygwin environment."

So much for "the Cygwin abomination"! :-)

And yes, it *also* mentions 'CoreUtils for Windows'.

Hi Frank,

I agree with you.

When I wrote this public service announcement, I was not trying to turn
Windows into a "development environment", as I was merely trying to get the
adb examples on the net to work inside the Windows command line interface.
C:\> adb shell pm list packages | grep -i gsf

As such, I had no intention of "staying" in the Linux environment, and, in fact, the only goal was to dive into Linux only when necessary, and then,
as soon as possible, to come back up to the surface, which is Windows CLI.

In essence, I was just dipping my toes in the Linux pool of water to grab something in the Linux pool of commands, and then stepping back out to the surface back into the fresh air of the Windows atmosphere. :)

At the time I posted this PSA, I was blissfully and completely unaware of
the Microsoft Rust CoreUtils, which, in and of themselves, solve much of
the problem set as they put grep (and a few other commands) in the path.

Notably missing from coreutils is awk & sed though, but they're in WSL.
But WSL commands aren't in the path, so that's why I added wsl2cli.bat.

They all have their place, where I apologize for calling Cygwin an "abomination", as that's just my memory of using it decades ago or so.

VMs are an abomination, if they still don't talk to the hardware
peripherals which are attached to Windows, but I gave up on VMs long ago
also, although I do note wryly that WSL2 is in a VM (although WSL1 is not).

As for Lawrence's link, I'm pretty sure he was employing sardonic sarcasm,
but I did read it with interest, as it contained an incorrect statement
that WSL doesn't use a VM, but what it may have meant is WSL2 doesn't
"feel" like a VM.

The main disadvantage (easily solved though) of WSL is that it doesn't put those Linux commands into your path, which is why I wrote wsl2cli.bat for
the team to benefit.

I do need to update wsl2cli.bat to only add to the path those commands
which come with WSL but which don't come with the coreutils (like sed/awk).
--
The best thing about Usenet is learning something useful from someone else.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

At Mon, 31 Aug 2026 11:50:59 -0600, Maria Sophia <mariasophia@comprehension.com> wrote:

Frank Slootweg wrote:

There is nothing wrong with the Cygwin abomination if you already
have it running, just as a Linux inside a VM is fine, if it talks
to your phone.

As I said before, Cygwin is way more complete and flexible than
both
'Coreutils for Windows' and GnuWin. *Because* it's more complete/
powerful than the other two, it encounters more Windows/Unix
differences, which it has to handle. That's not an "abomination",
but the consequence of its power.

BTW, Lawrence just posted a link to this

'How to set up Windows for software development' <https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>

which says

"Some other tools for developing in Windows are optional, but
useful:
...
* MSYS2 (MSYS2.MSYS2): A collection of tools for building Windows
binaries using the GCC compiler. Basically, an alternative to the
Visual Studio build stack based on the Cygwin environment."

So much for "the Cygwin abomination"! :-)

And yes, it *also* mentions 'CoreUtils for Windows'.

Hi Frank,

I agree with you.

When I wrote this public service announcement, I was not trying to
turn Windows into a "development environment", as I was merely trying
to get the adb examples on the net to work inside the Windows command
line interface.
C:\> adb shell pm list packages | grep -i gsf

adb -- Android Debug Bridge -- is a developer command.

(Although: I *have* built a web application around it, to control
digital signage, which is used by end users.)

(Remaining smarm snipped...)
--
-v System76 Thelio Mega v1.1 x86_64 Mem: 258G
OS: Linux 7.2.2 D: Mint 22.3 DE: Xfce 4.18 (X11)
NVIDIA GeForce RTX 3090Ti (24G) (610.57.04)
"I made it foolproof. They are making better fools!"
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Mon, 31 Aug 2026 09:34:18 -0600, Maria Sophia wrote:

WSL 1 used a translation layer. It intercepted Linux system calls
and translated them on-the-fly into Windows NT kernel system calls.

When Windows NT was first being developed, it was supposed to have the
concept of rCLpersonalitiesrCY, in the form of an extra plug-in layer on
top of the core kernel.

The Win32 API itself was implemented as one of these rCLpersonalitiesrCY.
Also a company called Softway Systems were granted access to the
documentation to how to create a new rCLpersonalityrCY, which they used to create a fairly-functional Unix-compatibility layer (better than the
piece of crap that was the POSIX-compliance layer that Microsoft
itself offered) called rCLInterixrCY
<https://en.wikipedia.org/wiki/Interix>.

Microsoft later restricted access to this documentation for
implementing rCLpersonalitiesrCY, and also acquired Softway/Interix, which
had the effect of ensuring that knowledge of how to do such things did
not spread any further outside the company.

Anyway, yourCOd think they would use this same rCLpersonalityrCY
architecture to implement WSL1. But apparently not. It never really
worked well, which is why it was abandoned in favour of a
full-function Linux kernel in WSL2 and later.

Oh, and think of going the other way, implementing a Windows
rCLpersonalityrCY on top of Linux: it exists in the form of WINE, and is working well enough that it is actually stealing market share from
Windows in the gaming market.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Lawrence D Oliveiro wrote:

Oh, and think of going the other way, implementing a Windows
|personalityi on top of Linux: it exists in the form of WINE, and is
working well enough that it is actually stealing market share from
Windows in the gaming market.

Ah, WINE. You bring back bad memories, given I gave up on WINE long ago,
but that's kind of the point, which is it has never been easy to add
another operating system to any operating system, although we all tried.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Mon, 31 Aug 2026 21:33:39 -0600, Maria Sophia wrote:

Lawrence D|+Oliveiro wrote:

Oh, and think of going the other way, implementing a Windows
rCLpersonalityrCY on top of Linux: it exists in the form of WINE, and
is working well enough that it is actually stealing market share
from Windows in the gaming market.

Ah, WINE. You bring back bad memories, given I gave up on WINE long
ago ...

Valve hasnrCOt. ItrCOs been including it with the well-regarded Steam Deck handheld gaming PC for some years now. And some vendors of
Windows-based handhelds are starting to offer it as an alternative OS
as well. ItrCOs that good -- not some fiddly experimental kludge any
more, but robust enough to support production code in the hands of
nontechnical users.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia, 2026-08-31 17:34:

Frank Slootweg wrote:

Also note that this article is not about replacing Windows as a
development platform, but about *adding* a Linux/Unix development
environment to it.

So as we've been saying all along: Linux cannot replace Windows, nor
vice versa.

I agree with both Lawrence & Frank in interpretation of this article
<https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>

And, like Frank, I note some sentences in particular such as
"Windows Subsystem for Linux (WSL) lets you work seamlessly
with Linux on Windows without the clunk and overhead of a VM."

When I saw that sentence, I checked the date of the article, which
surprised me was recent because it was my understanding WSL2 is inside a VM while WSL1 was not inside a VM (the core difference being native vs non-native Linux commands).

WSL2 *is* a VM provided by the VM subsystem of Windwos which also
provides Hyper-V and was used for the Android Subsystem which got
removed again.

The article writer just confused "no need to start VirtualBox or VMware"
with "no VM" - but of course Linux running in WSL is a VM as well.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Maria Sophia, 2026-09-01 05:33:

Lawrence D|+Oliveiro wrote:

Oh, and think of going the other way, implementing a Windows
-|personality-i on top of Linux: it exists in the form of WINE, and is
working well enough that it is actually stealing market share from
Windows in the gaming market.

Ah, WINE. You bring back bad memories, given I gave up on WINE long ago,
but that's kind of the point, which is it has never been easy to add
another operating system to any operating system, although we all tried.

WINE works very well here - *today*. You can not compare what you know
from 5 oder 10 years in the past with the current version.

Steam for Linux runs completely on WINE and the games often run *better*
than in Windows. I also have a number applications in WINE which work
just fine.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Wed, 9/2/2026 11:41 AM, Arno Welzel wrote:

Maria Sophia, 2026-08-31 17:34:

Frank Slootweg wrote:

Also note that this article is not about replacing Windows as a
development platform, but about *adding* a Linux/Unix development
environment to it.

So as we've been saying all along: Linux cannot replace Windows, nor
vice versa.

I agree with both Lawrence & Frank in interpretation of this article
<https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>

And, like Frank, I note some sentences in particular such as
"Windows Subsystem for Linux (WSL) lets you work seamlessly
with Linux on Windows without the clunk and overhead of a VM."

When I saw that sentence, I checked the date of the article, which
surprised me was recent because it was my understanding WSL2 is inside a VM >> while WSL1 was not inside a VM (the core difference being native vs
non-native Linux commands).

WSL2 *is* a VM provided by the VM subsystem of Windwos which also
provides Hyper-V and was used for the Android Subsystem which got
removed again.

The article writer just confused "no need to start VirtualBox or VMware"
with "no VM" - but of course Linux running in WSL is a VM as well.

The WSL2 is rootless when it comes to displaying things on screen. There
are more VHDX than this, but this is the one that is easily listed. The
Windows 7 "WinXP Mode" was also rootless and used Terminal Services for graphics injection, just like WSL2 does.

ext4.vhdx 10,316,939,264 bytes

When you use WSL2 and run "firefox", just a single Firefox window appears on the Windows desktop.

The VirtualBox and VMWare are rooted and display a rectangle which
represents the entire guest OS.

That's a difference in the display part of the hosting software.

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On 2026-09-02, Arno Welzel wrote:

Maria Sophia, 2026-08-31 17:34:

Frank Slootweg wrote:

Also note that this article is not about replacing Windows as a
development platform, but about *adding* a Linux/Unix development
environment to it.

So as we've been saying all along: Linux cannot replace Windows, nor
vice versa.

I agree with both Lawrence & Frank in interpretation of this article
<https://www.infoworld.com/article/4196853/how-to-set-up-windows-for-software-development.html>

And, like Frank, I note some sentences in particular such as
"Windows Subsystem for Linux (WSL) lets you work seamlessly
with Linux on Windows without the clunk and overhead of a VM."

When I saw that sentence, I checked the date of the article, which
surprised me was recent because it was my understanding WSL2 is inside a VM >> while WSL1 was not inside a VM (the core difference being native vs
non-native Linux commands).

WSL2 *is* a VM provided by the VM subsystem of Windwos which also
provides Hyper-V and was used for the Android Subsystem which got
removed again.

The article writer just confused "no need to start VirtualBox or VMware"
with "no VM" - but of course Linux running in WSL is a VM as well.

This reads a lot like those threads that arlow guy used to post... it's
not the same OP is it?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Paul, 2026-09-02 20:50:

[...]> When you use WSL2 and run "firefox", just a single Firefox window appears on

the Windows desktop.

The VirtualBox and VMWare are rooted and display a rectangle which
represents the entire guest OS.

VMware Workstation/Player also provided a mode where programs in the VM
are using their own Windows in inside the Windows desktop. However this required a special driver inside the VM since this was intended to be
used with Windows as VM guest and Windows does not have a concept like
X11 where single programs can use an X server instead of the one and
single frame buffer provided by the graphics card driver.

That's a difference in the display part of the hosting software.

It's more a difference in the operating systems running in the VM and
their Window managers. WSL2 for example requires X11 to make it possible
to have Linux programs running with their own Windows in the host. With
Wayland this is technically impossible without a lot of work to extend
Wayland for this.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On 2026-09-02 21:51, Dan Purgert wrote:

On 2026-09-02, Arno Welzel wrote:

Maria Sophia, 2026-08-31 17:34:

...

The article writer just confused "no need to start VirtualBox or VMware"
with "no VM" - but of course Linux running in WSL is a VM as well.

This reads a lot like those threads that arlow guy used to post... it's
not the same OP is it?

You mean Arlen? Yes, Arlen is Maria.

Grepping for arlow I see one Seamus Harlowe in 2021, just one post.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On 2026-09-02, Carlos E.R. wrote:

On 2026-09-02 21:51, Dan Purgert wrote:

On 2026-09-02, Arno Welzel wrote:

Maria Sophia, 2026-08-31 17:34:

...

The article writer just confused "no need to start VirtualBox or VMware" >>> with "no VM" - but of course Linux running in WSL is a VM as well.

This reads a lot like those threads that arlow guy used to post... it's
not the same OP is it?

You mean Arlen? Yes, Arlen is Maria.

Yeah, that's the one. Time to go fix some filters :)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Arno Welzel <usenet@arnowelzel.de> writes:

It's more a difference in the operating systems running in the VM and
their Window managers. WSL2 for example requires X11 to make it
possible to have Linux programs running with their own Windows in the
host. With Wayland this is technically impossible without a lot of
work to extend Wayland for this.

That work has evidently been done. The WSL2 display architecture is:

client -> [XWayland ->] Weston -> RDP -> Windows desktop

...with the XWayland part being optional, in the sense that you can run
Wayland clients under Linux and they display in their own independent
window on the Windows desktop.

https://github.com/microsoft/wslg gets into the details.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On 9/2/2026 8:25 PM, Dan Purgert wrote:

Yeah, that's the one. Time to go fix some filters :)

Looks like the Dan Purgert troll got through the filters.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Richard Kettlewell wrote:

Arno Welzel <usenet@arnowelzel.de> writes:

It's more a difference in the operating systems running in the VM and
their Window managers. WSL2 for example requires X11 to make it
possible to have Linux programs running with their own Windows in the
host. With Wayland this is technically impossible without a lot of
work to extend Wayland for this.

That work has evidently been done. The WSL2 display architecture is:

client -> [XWayland ->] Weston -> RDP -> Windows desktop

...with the XWayland part being optional, in the sense that you can run Wayland clients under Linux and they display in their own independent
window on the Windows desktop.

https://github.com/microsoft/wslg gets into the details.

--
https://www.greenend.org.uk/rjk/

Could it simply be that the main reason Linux GUI apps work differently in
a VM/WSL is mostly likely more about how the graphical systems are
connected and not because Windows inherently can't display Linux windows?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

vallor wrote:

C:\> adb shell pm list packages | grep -i gsf

adb -- Android Debug Bridge -- is a developer command.

WTF?
That's kind of like saying a hammer -- is a carpenter tool.

What's your point?
--
Most people seem to have religious belief systems based on zero facts.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On Wed, 9/2/2026 4:42 PM, Maria Sophia wrote:

Richard Kettlewell wrote:

Arno Welzel <usenet@arnowelzel.de> writes:

It's more a difference in the operating systems running in the VM and
their Window managers. WSL2 for example requires X11 to make it
possible to have Linux programs running with their own Windows in the
host. With Wayland this is technically impossible without a lot of
work to extend Wayland for this.

That work has evidently been done. The WSL2 display architecture is:

client -> [XWayland ->] Weston -> RDP -> Windows desktop

...with the XWayland part being optional, in the sense that you can run
Wayland clients under Linux and they display in their own independent
window on the Windows desktop.

https://github.com/microsoft/wslg gets into the details.

--
https://www.greenend.org.uk/rjk/

Could it simply be that the main reason Linux GUI apps work differently in
a VM/WSL is mostly likely more about how the graphical systems are
connected and not because Windows inherently can't display Linux windows?

Traditionally, you ran an application in Ring 3, to function as the display.

When I had a Mac, and wished to remote into work for a CAD session,
it was "MacX" you would run for X11.

When WSL (original edition) came out, it was XMing. One of the disks
on the other machine, still has the setup.

It's a solve-able problem.

One challenge, is not all distros are set up for native X11. There
is Wayland (and XWayland). I have one setup which is native X11, and
a benchmark makes it twice as fast as Wayland. The new shiny, costs.

Just finding a nice benchmark tool is a problem.

And when it comes to benching Windows and Linux, not all the players
are scrupulously honest. When Anandtech was around, on a few occasions
they tried running "desktop workloads" on server class machines. Just
to see what that would look like. They may have used a 48C 96T box or so, something roughly that size, and they noticed a "kink" in the bench curve,
just above 64 cores. They were running some Windows Pro thing at the time. Anand considered this worth chasing down, and it turned out, someone
answered his question, and told him he needed Windows Workstation for
more than 64 virtual cores, because Windows switches to "processor groups" above 64 cores, and Task Manager also starts using heat maps for the CPU display. Windows Enterprise is likely similarly endowed (but likely to be
more expensive than the Workstation SKU). When the benchmarks were rerun,
the curve no longer tipped at the end, but pointed more or less in the
right direction (subject to the usual effects from Intel ring buses
at the time). And today, I can find a review from someone you would
recognize, who put Windows Pro on such a machine and benchmarked it and
then produces a "quote-able number" for "how slow WIndows is".
After Anandtech made a splash all those years ago, with an admission
their first benchmarks were wrong, because they had used the wrong Windows OS.

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

On 27/08/2026 08.05, Maria Sophia wrote:

Usage of commands from a VM in microsoft windows is unrelated for Linux usergroups.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.msdos.batch

Richard Kettlewell, 2026-09-02 22:16:

Arno Welzel <usenet@arnowelzel.de> writes:

It's more a difference in the operating systems running in the VM and
their Window managers. WSL2 for example requires X11 to make it
possible to have Linux programs running with their own Windows in the
host. With Wayland this is technically impossible without a lot of
work to extend Wayland for this.

That work has evidently been done. The WSL2 display architecture is:

client -> [XWayland ->] Weston -> RDP -> Windows desktop

...with the XWayland part being optional, in the sense that you can run Wayland clients under Linux and they display in their own independent
window on the Windows desktop.

https://github.com/microsoft/wslg gets into the details.

Thanks, I wasn't aware of this.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.22a-Linux NewsLink 1.2