Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.android > #155333 > unrolled thread

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

Back to article view | Back to comp.mobile.android

Contents

  PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-26 20:08 -0600
    Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-27 00:05 -0600
      Re: PSA: How to add WSL grep to the Windows command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-29 23:05 -0600
        Re: PSA: How to add WSL grep to the Windows command-line PATH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-30 06:56 +0000
          Re: PSA: How to add WSL grep to the Windows command-line PATH Paul <nospam@needed.invalid> - 2026-08-30 05:26 -0400
            Re: PSA: How to add WSL grep to the Windows command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-30 08:23 -0600
            Re: PSA: How to add WSL grep to the Windows command-line PATH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-30 23:31 +0000
      Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-30 20:53 -0600
        Re: PSA: How to add WSL grep to the Windwos command-line PATH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-31 05:34 +0000
          Re: PSA: How to add WSL grep to the Windwos command-line PATH Frank Slootweg <this@ddress.is.invalid> - 2026-08-31 12:45 +0000
            Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-31 09:34 -0600
              Re: PSA: How to add WSL grep to the Windwos command-line PATH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-31 22:28 +0000
                Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-31 21:33 -0600
                  Re: PSA: How to add WSL grep to the Windwos command-line PATH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-01 07:31 +0000
                  Re: PSA: How to add WSL grep to the Windwos command-line PATH Arno Welzel <usenet@arnowelzel.de> - 2026-09-02 17:44 +0200
              Re: PSA: How to add WSL grep to the Windwos command-line PATH Arno Welzel <usenet@arnowelzel.de> - 2026-09-02 17:41 +0200
                Re: PSA: How to add WSL grep to the Windwos command-line PATH Paul <nospam@needed.invalid> - 2026-09-02 14:50 -0400
                  Re: PSA: How to add WSL grep to the Windwos command-line PATH Arno Welzel <usenet@arnowelzel.de> - 2026-09-02 22:00 +0200
                    Re: PSA: How to add WSL grep to the Windwos command-line PATH Richard Kettlewell <invalid@invalid.invalid> - 2026-09-02 21:16 +0100
                      Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-09-02 23:42 +0300
                        Re: PSA: How to add WSL grep to the Windwos command-line PATH Paul <nospam@needed.invalid> - 2026-09-02 21:36 -0400
                      Re: PSA: How to add WSL grep to the Windwos command-line PATH Arno Welzel <usenet@arnowelzel.de> - 2026-09-04 18:37 +0200
                Re: PSA: How to add WSL grep to the Windwos command-line PATH Dan Purgert <dan@djph.net> - 2026-09-02 19:51 +0000
                  Re: PSA: How to add WSL grep to the Windwos command-line PATH "Carlos E.R." <robin_listas@es.invalid> - 2026-09-02 22:05 +0200
                    Re: PSA: How to add WSL grep to the Windwos command-line PATH Dan Purgert <dan@djph.net> - 2026-09-02 20:25 +0000
                      Re: PSA: How to add WSL grep to the Windwos command-line PATH CDB <bellemarecd@gmail.com> - 2026-09-02 22:39 +0200
      Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-30 21:03 -0600
    Re: PSA: How to add WSL grep to the Windwos command-line PATH Paul <nospam@needed.invalid> - 2026-08-27 04:36 -0400
      Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-27 10:45 -0600
        Re: PSA: How to add WSL grep to the Windwos command-line PATH Paul <nospam@needed.invalid> - 2026-08-27 14:44 -0400
          Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-27 12:59 -0600
            Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-27 13:16 -0600
          Re: PSA: How to add WSL grep to the Windwos command-line PATH Frank Slootweg <this@ddress.is.invalid> - 2026-08-27 19:41 +0000
            Re: PSA: How to add WSL grep to the Windwos command-line PATH vallor <vallor@vallor.earth> - 2026-08-27 20:03 +0000
              Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-27 19:18 -0600
                Re: PSA: How to add WSL grep to the Windwos command-line PATH Herbert Kleebauer <klee@unibwm.de> - 2026-08-28 12:13 +0200
                  Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-28 09:51 -0600
                    Re: PSA: How to add WSL grep to the Windwos command-line PATH Herbert Kleebauer <klee@unibwm.de> - 2026-08-28 18:24 +0200
                      Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-28 11:13 -0600
                        Re: PSA: How to add WSL grep to the Windwos command-line PATH Herbert Kleebauer <klee@unibwm.de> - 2026-08-28 19:36 +0200
                          Re: PSA: How to add WSL grep to the Windwos command-line PATH Frank Slootweg <this@ddress.is.invalid> - 2026-08-28 18:25 +0000
                            Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-28 13:06 -0600
                        Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-28 12:18 -0600
            Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-27 19:37 -0600
              Re: PSA: How to add WSL grep to the Windwos command-line PATH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-28 04:28 +0000
                Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-28 10:46 -0600
          Re: PSA: How to add WSL grep to the Windows command-line PATH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-28 01:21 +0000
            Re: PSA: How to add WSL grep to the Windows command-line PATH Paul <nospam@needed.invalid> - 2026-08-27 22:21 -0400
              Re: PSA: How to add WSL grep to the Windows command-line PATH Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-28 04:25 +0000
                Re: PSA: How to add WSL grep to the Windows command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-27 23:35 -0600
        Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-28 10:25 -0600
          Re: PSA: How to add WSL grep to the Windwos command-line PATH Paul <nospam@needed.invalid> - 2026-08-28 15:37 -0400
            Re: PSA: How to add WSL grep to the Windwos command-line PATH "Carlos E. R." <robin_listas@es.invalid> - 2026-08-29 13:16 +0200
              Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-29 16:27 -0600
    Re: PSA: How to add WSL grep to the Windwos command-line PATH Arno Welzel <usenet@arnowelzel.de> - 2026-08-30 12:58 +0200
      Re: PSA: How to add WSL grep to the Windwos command-line PATH "Kerr-Mudd, John" <admin@127.0.0.1> - 2026-08-30 12:48 +0100
        Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-30 08:23 -0600
    Re: PSA: How to add WSL grep to the Windwos command-line PATH Brian Gregory <void-invalid-dead-dontuse@email.invalid> - 2026-08-31 01:15 +0100
      Re: PSA: How to add WSL grep to the Windwos command-line PATH Maria Sophia <mariasophia@comprehension.com> - 2026-08-30 20:19 -0600

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#155575

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

[toc] | [prev] | [next] | [standalone]

#155619

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

[toc] | [prev] | [next] | [standalone]

#155533

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?

[toc] | [prev] | [next] | [standalone]

#155538

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.
ES🇪🇸, EU🇪🇺;

[toc] | [prev] | [next] | [standalone]

#155541

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

[toc] | [prev] | [next] | [standalone]

#155554

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.

[toc] | [prev] | [next] | [standalone]

#155406

Lawrence D¢Oliveiro 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.

[toc] | [prev] | [next] | [standalone]

#155346

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.
>  C:\> 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.
>  C:\> wsl --list --verbose
>         NAME      STATE           VERSION
>       * Ubuntu    Stopped         1
> 
> And, let's prove WSL has a working grep too.
>  C:\> wsl grep --version
>       grep (GNU grep) 3.11
> 
> Since it's there, let's add a "grep.cmd" to a file in our path:
>  C:\> gvim C:\path-to\grep.cmd
>       @wsl grep %*
> 
> Then test from anywhere on the command line:
>  C:\> grep --version
>       grep (GNU grep) 3.11
> 
> Let's get back to what we were doing, which was testing GSF:
>  C:\> 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

[toc] | [prev] | [next] | [standalone]

#155352

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:
 C:\> 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
 C:\> 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.

[toc] | [prev] | [next] | [standalone]

#155354

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:
>  C:\> 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
>  C:\> 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

[toc] | [prev] | [next] | [standalone]

#155355

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.

[toc] | [prev] | [next] | [standalone]

#155356

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.

[toc] | [prev] | [next] | [standalone]

#155358

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.

[...]

[toc] | [prev] | [next] | [standalone]

#155359

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

[toc] | [prev] | [next] | [standalone]

#155365

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

C:> 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	
.

[toc] | [prev] | [next] | [standalone]

#155372

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.

[toc] | [prev] | [next] | [standalone]

#155373

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.

[toc] | [prev] | [next] | [standalone]

#155374

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

[toc] | [prev] | [next] | [standalone]

#155377

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.
 C:\> adb shell dumpsys battery | grep level
        level: 95 
 C:\> 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.
 C:\> 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.

[toc] | [prev] | [next] | [standalone]

#155378

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.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.mobile.android

csiph-web