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 3 of 3 — ← Prev page 1 2 [3]

#155380

Herbert Kleebauer <klee@unibwm.de> wrote:
> 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.

  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.

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

#155381

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?

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

#155379

Maria Sophia wrote:
> 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%

UPDATE

Running this inside quotes directly on the adb shell worked fine because 
it was executed entirely inside Android's Linux environment:
 C:\> adb shell "dumpsys battery | awk '/level:/ {print \"Battery Level:\", $2 \"%\"}'"
      Battery Level: 94%

But it had failed when running inside the Windows command line.
 C:\> 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:
 C:\> 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...
 C:\> type awk.cmd
       @wsl awk %*
 C:\> 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.
 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 
-- 
Android, Windows & Linux walk into a bar to discuss their differences.

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

#155367

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.

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

#155370

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, it’s 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

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

#155376

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

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

#155366 — Re: PSA: How to add WSL grep to the Windows command-line PATH

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

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

#155368 — Re: PSA: How to add WSL grep to the Windows command-line PATH

On Thu, 8/27/2026 9:21 PM, Lawrence D’Oliveiro 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

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

#155369 — Re: PSA: How to add WSL grep to the Windows command-line PATH

On Thu, 27 Aug 2026 22:21:14 -0400, Paul wrote:

> On Thu, 8/27/2026 9:21 PM, Lawrence D’Oliveiro 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 doesn’t.

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

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

#155371 — Re: PSA: How to add WSL grep to the Windows command-line PATH

Lawrence D¢Oliveiro 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 doesn¢t.
> 
> <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:
 C:\> 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).

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

#155375

Maria Sophia wrote:
> Then we need to add coreutils to the Windows path
>  C:\> 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.

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

#155382

On Fri, 8/28/2026 12:25 PM, Maria Sophia wrote:
> Maria Sophia wrote:
>> Then we need to add coreutils to the Windows path
>>  C:\> 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

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

#155383

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

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

#155386

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

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

#155390

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

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

#155391

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.

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

#155393

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.

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

#155401

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

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

#155404

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.

[toc] | [prev] | [standalone]

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

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

csiph-web