WK 2026: Scoor de beste deals! Stel jouw winnende opstelling samen met behulp van ons advies.

Microsoft Coreutils brengt Unix/Linux-invloed naar Windows' commandprompt

Microsoft brengt Coreutils for Windows uit, waarmee het meer dan 75 Unix-commando's opneemt in zijn eigen platform. Coreutils is gebaseerd op een herimplementatie van GNU Coreutils. Deze herimplementatie zit standaard al in moderne Linux-distro's.

De op GitHub gepubliceerde previewsoftware geeft gebruikers een set tools in de commandprompt van Windows en in PowerShell. Deze hulpmiddelen zijn gelijk aan wat al beschikbaar is op Linux, macOS en Microsofts Windows Subsystem for Linux (WSL). Met WSL draait Windows een volledige Linux-installatie zonder virtualisatiesoftware.

Microsoft-ceo Satya Nadella presenteerde Coreutils als uiting van liefde voor Linux op de Build-conferentie van zijn bedrijf. Het krachtige zoekcommando grep (global regular expression print) bevindt zich in de lijst van commando's in Microsofts Coreutils. Deze in Rust geschreven software voor Windows omvat ook de oorspronkelijke DOS-commando's sort en find. Eerder voegde Microsoft al bekende Linux-commando's als curl en sudo toe aan de commandprompt in Windows, schrijft The Register.

Ceo Satya Nadella, Microsoft houdt van Linux. Bron: Microsoft
Ceo Satya Nadella, Microsoft houdt van Linux. Bron: Microsoft

Door Jasper Bakker

Nieuwsredacteur

04-06-2026 • 15:31

46

Submitter: KipKroket

Reacties (46)

Sorteer op:

Weergave:

Coreutils is GNU, niet Linux :-)
Je hebt nu ook Ubuntu coreutils bijvoorbeeld, wat een rewrite is in rust.
Dat zegt toch ook niemand, meeste zo niet alle van deze Core Utils zijn in eerste plaats afkomstig uit Unix, en zijn later via GNU geport naar Linux, vandaar dat deze nu genoemd worden.
Coreutils is gebaseerd op een herimplementatie van GNU Coreutils
Vanuit het artikel!!
Grappig dat ze het brengen als liefde voor Linux. Ik dacht altijd dat de coreutils nou juist het GNU-gedeelte was, en Linux alleen de kernel. Samen GNU/Linux.

Wordt het nu GNU/Windows?
I'd just like to interject for a moment. What you're refering to as Windows, is in fact, GNU/Windows...
Je vergeet een plaatje van Stallman in hawaii-shirt ;)
In een ver verleden was Windows nog POSIX compatible. Met WSL1.0 waren ze weer soort van POSIX compatible.

Straks zijn ze weer POSIX compatible? Maar voor hoe lang.
Ik heb een YouTube filmpje gezien, weet niet van wie, maar die zei echt dat Microsoft dingen niet doet in Linux-interest, maar in hun eigen interest. Daar was ik eigenlijk wel mee eens, hoe goed ze het ook willen verkopen met hun Microsoft loves Linux campagne. Dit trucje hebben ze ook vaker uitgehaald namelijk, niet alleen met Linux.

Microsoft doet zeker veel commits aan de kernel, de meeste zijn echter wel voor hun eigen dingen: HyperV, WSL en Azure. Kijkend naar iemand als Google en Valve, dan zie je hele andere patches en contributies. Dat ze nu ook pushen voor Fedora (RHEL) komt niet voor hun 'Linux-distro liefde', dat is een besparing en winst op minder personeel.

Ze gaan echt niet hun eigen ecosysteem en doelgroep om zeep helpen. die integratie met de tools zijn er dat scripts van Linux ook (grotendeels) werken op Windows. Bij WINE is juist het gedaan zonder enige broncode, iets dat MS wel zonder issues kan doen.

Het is alsof ik jouw niet mijn recept geef, maar wel jouw recept gebruikt in mijn eigen cake om die super lekker te maken.

[Reactie gewijzigd door HollowGamer op 4 juni 2026 16:01]

Ik zie het eigenlijk wel gebeuren dat Microsoft dit op dezelfde manier als in 1993, bij de eerdere "handreiking" vanuit Microsoft om het server OS Windows NT 3.1 nèt voldoende "POSIX compatible" te maken met de POSIX.1-1990 subsystem integration, zal implementeren.

Daardoor konden veel eenvoudige POSIX-programma’s na hercompilatie draaien op Windows NT. Bovendien behaalde NT daadwerkelijk de vereiste FIPS 151-2 certificering voor Amerikaanse overheidsopdrachten. Dat was ook het enige waar het hen om ging. Ze moesten de grote opdracht binnenhalen. Het was eerder een POSIX API-laag dan een Unix-omgeving. Het was m.i. een gevalletje veel beloven, weinig (lees: bare minimum) waar maken. (zie ook Wikipedia: Microsoft POSIX subsystem)

I know, "De in het verleden behaalde resultaten zijn geen garantie voor de toekomst.", maar ik houd zo'n actie wel in mijn achterhoofd.

Verder was WSL een zeer goed verwelkomde toevoeging aan Windows. coreutils brengt hierin echter juist dat eerdere verhaal naar boven. Call it a trauma... :+
Coreutils zijn "slechts" wat tooltjes, maar het GNU deel van GNU/Linux omvat veel meer dan dat.
Bijv libc gcc make binutils bash find diff gettext.
Daarom was dat (iig in het begin) wel een eervolle vermelding waard.
Bovendien, deze coreutils komen niet van GNU maar zijn een herimplementatie.
Ehh unix commandos? Bovendien is het aandeel ‘gnu’ in gnu/linux verhoudingsgewijs zodanig tegenwoordig dat het eigenlijk teveel eer is voor gnu om nog expliciet steeds in een mond genoemd te worden. Het voegt weinig toe om het te benoemen.
Een leuke theorie die ik las over waarom dit en waarom nu, is dat de LLMs maar linux commando's blijven gebruiken wat het gebruik op windows in de weg zit.

Dus i.p.v. de LLMs beter krijgen, gewoon maar opgeven en mee gaan
Ik heb dit letterlijk nog nooit meegemaakt. Ik krijg altijd netjes powershell voorgeschoteld. Ik hoop eigenlijk dat de coreutils een powershell-implementatie hebben zodat we netjes objecten terug krijgen ipv plain text.
Het hangt van je instructies af, maar ik zie het nog regelmatig voorbij komen, ook als het al zeker moet weten dat ik op Windows werk.
Dat is wel een vergezochte theorie, want dat is namelijk niet wat LLM's daadwerkelijk doen op Windows. Ze gebruiken 9 van de 10 keer een gebundelde versie van ripgrep (rg) en Codex schakelt moeiteloos over op PowerShell op het moment dat de environment aangeeft dat het een Windows 11 machine betreft.
Claude wil bij mij regelmatig gewoon cat/echo/grep enzo uitvoeren. Dat werkt dan wel, want dit is een linux bak. Ik denk dat die, net als wat jij zegt met Codex, gewoon in de context heeft staan welk OS en welke shell de llm op draait (en waarschijnlijk nog veel meer info).
Maar het kost je wel telkens tokens en tijd. Nou zullen ze die tokens niet zo belangrijk vinden, tijd is wel van invloed. Vooral als eerste "oh wat gaat er fout" validaties is het handig als er snel een oplossing gevonden wordt.
Dan zullen diezelfde llm’s ook wel unix bestandspaden uitschrijven. Gaat Windows die dan ook ondersteunen? :+
MS is wel goed met het ondersteunen van zowel `/` als `\` als path separator
Dat werkt al jaren prima, inclusief het beheer van rechten. Op elk systeem waar ik wat mee moet doe installeer ik als jaren GOW (zie GitHub). Dan heb ik de belangrijkste commandos bij elkaar. Met cygwin kon dit ook al.
Dan kunnen we mooi de output van more pipen naar less :+ OT: een mooie toevoeging.
Natuurlijk moet ik nu even Henry Spencer quoten :)

"Those who don't understand UNIX are doomed to reinvent it, poorly"

...En ben uiteraard benieuwd wanneer de MS Windows kernel vervangen wordt 8-)

[Reactie gewijzigd door zordaz op 4 juni 2026 15:40]

Eindelijk zien ze daar ook het licht in plaats van hun eigen PowerShell-rommel.

Wil je gewoon de inhoud van een directory weten, grootste file eerst, moet je eerst in alle documentatie graven naar van alles, om uiteindelijk uit te komen op
> Get-Process | Sort-Object -Property WS

Ik tik
>ls -S
in en ben er, iets dat gewoon in de man ls zit, als je het toevallig vergeet. Dan gaan we het dus maar niet hebben over het zoeken in een file, waar ze nu eindelijk grep voor hebben.

Update: Ik had de WerkSet (whatever that may be), een betere versie is volgens mij:
> Get-ChildItem -path ./ -File | Sort-Object -Property length -Descending

[Reactie gewijzigd door FreezeXJ op 4 juni 2026 16:02]

Is toch dir, of ben ik nou gek? Om nou meteen Powershell zo af te schilderen gaat wel ver.
Dir spuugt alle entries wel uit, maar sorteert er nog niks aan, en ik krijg alleen maar foutmeldingen als ik probeer em argumenten mee te geven in een PowerShell. Voorbeeldje van https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dir (DIR /OS of /O-S) werkt niet in PS, wel in een oude CMD-shell... Lekker consistent dus. Maar ik hou me aanbevolen voor een kortere notatie in PS om de inhoud van een directory te laten zien met grootste files eerst.
ls | sort length -des

Je loopt gewoon dingen af te branden die je niet kent, als een echte boer :P. Ik kan dat ook met die Linux tools: ik vind ze maar klote omdat ze allemaal string based zijn. Waardeloos.

Objects > String based anytime.

[Reactie gewijzigd door Glashelder op 4 juni 2026 16:15]

Ik moest vorige week een tooltje gebruiken dat alleen op Windows werkte. Ik heb al jaren geen Windows meer, dus ik was aangewezen op een virtual machine in UTM. Omdat ik op een Mac met M-processor werk, moest die VM ook nog eens op een geëmuleerde x86 processor draaien. Je begrijpt dat dat alles behalve snel ging. Toen ik een CLI nodig had, klikte ik per ongeluk PowerShell aan. Niet te doen zo traag. Letterlijk elke letter zag ik verschijnen. Alsof ik naar ChatGPT van 2 jaar geleden zat te kijken. Daarna good old cmd.exe geprobeerd: probleemloos en snel.

Lang verhaal kort: ik ben er niet van overtuigd dat die “objecten” altijd beter zijn. (Nog los van het feit dat die collectie van tekstgebaseerde Unix-tools al decennia super goed samenwerkt.)
Uhmm dat klopt niet.

Nu sorteer je de processen op Werkset grote.

Dat is iets heel anders dan files in een directory.

EDIT: omdat ik deze vraag interessant vond heb ik even gekeken naar de output van ls -S en dit vergeleken met wat in powershell werkt.

> dir | sort Length -Desc

Dit was de kortste optie die ik kon vinden die ongeveer hetzelfde resultaat geeft. Unix LS geeft alleen de bestandnamen terug (getest met WSL), Powershell geeft een tabel terug met header en allemaal andere properties.

Maar moet zeggen dit was lastig terug te vinden in de help functie.

[Reactie gewijzigd door ocwil op 4 juni 2026 16:17]

Het is vooral gewenning. Wanneer ik een tijdje met Powershell werk en de logica klikt, gaat dat heel soepel.

Er zit best fijne logica achter, het is alleen allemaal meer type werk ten opzichte van bash. Verder is het object oriented wel gaaf, je kan dus alle objecten in Windows manipuleren en dat is echt donders krachtig. Dit lukt met bash niet. Files manipuleren en services herstarten, dat wel. Of wanneer applicaties het expliciet ondersteunen.

Overigens vertaalt Powershell ook best veel bash commands. Want ook in powershell werkt: man ls
Geinig, als ik idd man ls intik, krijg ik

NAME
Get-ChildItem

ALIASES
gci
ls
dir

en dan de rest van de syntax. Stiekem hebben ze dus al wel wat simpele Linux-opties erin, alleen de argumenten moeten nog in PowerStyle gegeven worden.
Ik geloof best dat het heel mooi speelgoed kan worden, maar het vereist inderdaad een eigen hersenkronkel om te snappen. Die mis ik dus :+
Powershell is inderdaad even wennen qua syntax maar zodra het klikt is en logisch en enorm krachtig juist dankzij het OO ontwerp.
Overigens vertaalt Powershell ook best veel bash commands. Want ook in powershell werkt: man ls
Het fijne hierbij is dat je bij gebruik van bash commandos in Powershell je gewoon objecten terug krijgt.
Je wordt hopelijk toch niet gedwongen PowerShell te gebruiken?

Ik heb er nooit iets in gezien, de meeste scripts lijken ook vrij gevoelig voor hacks en exploits. Wat PS zou moeten hebben opgelost.
Mooi, nog even de rest van het OS porten en dan kunnen we Windows achterwege laten :+
Ik kan een zo-goed-als enkele terminalsyntax alleen maar toejuichen. Tuurlijk, op dit moment zal je al heel snel tegen de limieten van wat je in Windows qua unix-commands kan doen aanlopen. Maar hopelijk leidt dit tot meer en meer.

...Misschien totdat, onder de motorkap, Windows een bepaalde open-source kernel gebruikt...?

A man can dream!
Geloof a.u.b. Microsoft niet op hun mooie woorden. Het is een miljarden bedrijf, die gaan echt niet iets doen omdat hun belangrijkste inkomstenbron weg te halen.

De huidige Microsoft engineers blijven er bij, juist doordat ze vastzitten in hun ecosysteem. Je kunt op Windows 10, bijvoorbeeld prima* NT4.0 draaien. Daar zit hun kracht (en zwakte ook).
Deze hulpmiddelen zijn gelijk aan wat al beschikbaar is op Linux, macOS en Microsofts Windows Subsystem for Linux (WSL).
Dat klopt niet helemaal. macOS gebruikt BSD implementatie van deze tools welke afwijkt van GNU coreutils. Je ziet dit b.v. in hoe de sed (BSD) en gsed (GNU) flaggen afwijken waardoor het resultaat dus anders is.
Grappige is dat Canonical daar nu ook achterkomt met hun coreutils rewrite. Je verwacht iets wat logisch is, maar toch zijn er uitzonderingen op die regel mogelijk.
Enerzijds wel blij mee, scheelt weer tokens en tijd. Anderzijds is het voor LLMs wel weer mogelijk dat het op andere plekken weer ineens fout gaat. Vooral als het bestandspaden gaat aannemen en meer. Nu weten ze direct dat het fout gaat, straks wordt dat lastiger.

Om te kunnen reageren moet je ingelogd zijn