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

Reacties (96)

[jeroenvj]

Coreutils is GNU, niet Linux :-)

[HollowGamer]

Je hebt nu ook Ubuntu coreutils bijvoorbeeld, wat een rewrite is in rust.

[Eärendil]

Rust heeft natuurlijk aantoonbaar voordelen m.b.t. security-issues die gerelateerd zijn aan verkeerd geheugengebruik, maar Rust is beschermd je niet tegen alle soorten fouten.

Bij dit soort herimplementaties van standaard tools die al tientallen jaren in een C-versie uitontwikkeld zijn vraag ik me af wanneer een nieuwe Rust-versie even veilig is als de oude bestaande code.

[Marcel--]

Terechte vraag: oudere versies van uutils waren nogal eens vatbaar voor TOCTOU race conditions, maar na een audit (b)lijken ze veiliger: https://www.heise.de/news/Rust-Coreutils-0-9-0-weniger-unsafe-mehr-Tempo-11315063.html

[fastedje]

De rewrite van coreutils in Rust komt voorlopig qua bugs, CVEs en ontbrekende features niet eens in de buurt van de oude GNU .coreutils. Cannonical gaat desalniettemin toch gewoon door met de uitrol van deze Rust coreutils.

[MartineEekhof]

Dat is toch fish?

[rubenvb]

Fish "vervangt" Bash, niet de GNU Coreutils.

Ubuntu gebruikt nu ook dezelfde uutils coreutils waar hier Microsoft dus een niet-fork fork heeft gemaakt.

[Bamboozled]

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.

[Mark de Vaal]

Coreutils is gebaseerd op een herimplementatie van GNU Coreutils

Vanuit het artikel!!

[diondokter]

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

[batjes]

Maar Windows kan veel Linux commando's, het vertaald een hele zwits veelgebruikte Linux commando's naar de Powershell variant.

Het zal voor een LLM appeltje-eitje zijn om op de powershell docu getrained te worden i.p.v. bash manpage(s).

[Travelan]

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.

[Ghoelian]

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

[batjes]

Cat en echo werken anders prima in powershell. Alleen grep niet.

[Ghoelian]

Ah dat wist ik niet. Ben wel benieuwd of ze die bestaande commands dan ook gaan vervangen door de coreutils versie.

[Kobboi]

Grep is dan ook geen coreutil, maar zijn eigen GNU project.

[batjes]

cat en echo worden door powershell vertaald naar hun powershell gelijkwaardige, net als nog een stapeltje linux commandos. Heeft wat dat betreft niets met coreutils te maken.

[Kobboi]

En ik wou maar aangeven dat het me niks verbaast dat grep daar niet bij zit, omwille van de reden die ik aangaf: cat en echo zijn binaries uit het coreutils project (al wordt die laatste vaak om performantieredenen afgevangen door een implementatie in de shell), grep is grep.

Het zou me niks verbazen dat dat "stapeltje linux commandos" ook allemaal coreutils zijn. En om je helemaal boos te maken ( ): het zijn net geen "linux commandos" maar GNU tools, in de zin dat ze OS-onafhankelijk zijn. De essentiele tools die specifieke Linux-functionaliteit vereisen zitten namelijk in het util-linux package/project.

[batjes]

Dat stapeltje linux commando's zijn dus niet meer dan een alias naar de Powershell tegenhangers. Dit zit al vele jaren in Powershell, volgens mij sinds 5 al en heeft dus niets met coreutils of GNU te maken.

Ik vind juist raar dat grep er niet bij zit, want select-string bestaat.

[musiman]

In plaats van grep kun je in windows findstr gebruiken. Die is ook behoorlijk krachtig.

[Martinspire]

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.

[Wolfos]

Ik gebruik Codex zowel op MacOS als op Windows en het is echt niet grappig meer hoeveel slechter dat op Windows werkt. Niet alleen de sandbox die vaak niet werkt, maar ook inderdaad veel meer fouten met Powershell dan met ZSH.

[hottestbrain]

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.

[Martinspire]

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.

[biteMark]

Dan zullen diezelfde llm’s ook wel unix bestandspaden uitschrijven. Gaat Windows die dan ook ondersteunen?

[diondokter]

MS is wel goed met het ondersteunen van zowel `/` als `\` als path separator

[satya]

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.

[lezzmeister]

Oneens. Dat heeft veel en grote gevolgen voor allerhande drivers, aansturing, hardware, etc. Dan nog de licentie bende.

Als het op de FreeBSD kernel of RustOs is dan is er mogelijk wel wat voor te zeggen maar blijft een enorm grote operatie met te grote gevolgen voor de standaard gebruiker.

Wat ik wel vind is dat Windows wat meer moet afkijken bij andere besturingssystemen. Ik kan dan een scheduler kiezen, zonder gedoe een ssd of Xpoint drive als cache inzetten voor een harde schijf lokaal of op een ander systeem, onderdelen wel of niet installeren, de /home of /users map op een andere drive dan het os, dat zou in Windows ook gewoon allemaal moeten kunnen. Ik zou Everything, Primocache, Icaros, Qdir of Revo gewoon niet nodig moeten hebben.

[Kul]

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?

[Ghoelian]

I'd just like to interject for a moment. What you're refering to as Windows, is in fact, GNU/Windows...

[mvkdev]

Je vergeet een plaatje van Stallman in hawaii-shirt

[batjes]

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.

[beerse]

Daarnaast is eind vorige eeuw de posix standaard al zodanig aangepast dat microsoft haar 'nieuwe' operating systeem er ook onder zou moeten kunnen krijgen. Om mswindows nt3.5 en/of nt4 naar posix te tillen moest je extra pakketten installeren die op de extra-cd stonden. Of/waar/hoe dat met nt5 is gebeurt heb ik niet meer op mijn netvlies. De usa-overheid wenste/eiste ooit de posix standaard voor door haar gebruikte computers maar zij heeft posix volgens mij ondertussen uit de eisen voor computers gehaald.

[HollowGamer]

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]

[kuurtjes]

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

Langs de andere kant, wil ik jouw recept wel als jij het mijne gebruikt? Als Windows Linux nodig heeft maar niet andersom zegt dat ook wel genoeg

[moimeme]

Was mono niet die andersom?

[InjecTioN]

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

[phyck]

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

Bwa, dan zou ik microsoft toch eeder klasseren onder uitzondering op de regel

[N8w8]

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.

[PjotterP]

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.

[zordaz]

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

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

[MSalters]

De NT kernel heeft z'n roots in VMS, en er wordt wel vrij breed erkend dat het een prima kernel is. Async is pas recent in Linux populair geworden, NT had het 35 jaar geleden al.

[batjes]

NT gaat (lange tijd) nergens heen want Azure en M365 draaien er op.

[readefries]

Hmmn, als ik kijk naar de repo die ze hebben opgezet zitten er nog wel wat haken en ogen aan:

• omgang met regeleindes, gezien Windows daar anders mee omgaat zou ik verwachten dat ze dit in de tools netjes afvangen;
• geen `/dev/null`;
• geen POSIX signaal (SIHUP, SIGPIPE en SIGUSR);
• de werking van bestandsrechten;

Het voelt nog wat fragiel en zaken die je op elk GNU/Linux systeem voor lief kan nemen kunnen anders werken.

[MSalters]

Posix signals zijn een OS concept, geen shell. Het gaat ook niet komen - POSIX signals stammen uit de single-core tijd en Windows NT is vanaf het begin opgezet voor multi-threading

[xorpd]

Wat een onzin. Signals zijn prima te gebruiken in een multi-threaded omgeving. En werken ook prima op Windows, test maar eens in WSL1.

[MSalters]

Signals zijn gericht aan een proces, niet aan een thread. Ze komen op een random thread binnen. Een random Windows thread verwacht dat niet en kan crashen.

WSL1 runt geen Windows threads maar Linux threads (wsl2 idem).

[xorpd]

WSL1 zijn 'gewoon' Windows threads, check de Task Manager maar. Het verschil is dat ze een andere system call interface hebben. Die vervolgens weer in Windows system calls vertaald worden. Zo heeft NT ook een fork system call, maar die is alleen exposed richting WSL.

[batjes]

nvm

[Reactie gewijzigd door batjes op 5 juni 2026 14:16]

[Stoney3K]

'alias NUL /dev/null; alias NUL /dev/zero' en Bob is je oom. :+

NUL zit er al sinds het begin in als character device waar je alleen nullen uit haalt en waar je alles in kan laten verdwijnen, dus zo moeilijk is dat niet.

Wat meer een ding is is dat Windows sowieso niet echt een besef heeft van Unix-style device nodes (of het /dev bestandssysteem) dus het is niet zo dat je blindelings Linux programma's op Windows kan compilen en verwachten dat het zomaar werkt.

[oef!]

Dan kunnen we mooi de output van more pipen naar less OT: een mooie toevoeging.

[MaartenBW]

`less` zit niet in Coreutils, maar is een aparte utility.

[Stoney3K]

Omschrijving van de package: "less is more", ofwel, geschreven als een vervanging van 'more' waarschijnlijk vanwege rechten.

[moimeme]

More kon alleen vooruit, gewoon per scherm pagen. less kwam als een more met meer opties, onder andere backward scrollen en zoeken (ook bij starten) wat een gigantische verbetering was.

Allebei zijn public domein, de naam less was een wordenspeel.

Een omschrijving was ook: "less is more, more or less"

[Reactie gewijzigd door moimeme op 5 juni 2026 18:56]

[nehal3m]

Mooi, nog even de rest van het OS porten en dan kunnen we Windows achterwege laten

[readefries]

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.

[HollowGamer]

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.

[batjes]

Met WSL draait Windows een volledige Linux-installatie zonder virtualisatiesoftware.

WSL2.0 is wel virtualisatie en draait boven op Hyper-V.

WSL1.0 was geen virtualisatie.

[HollowGamer]

Dit klopt inderdaad. Ik dacht een soort mini kernel in WSLv2, en op WSLv1 was het vooral snel met eigen Windows zaken.

Beide vond ik nog langzaam destijds (4 jaar geleden), maar denk dat tegenwoordig het vrij snel is?

[batjes]

WSL1 was met sommige dingen best wel goed qua snelheid en ik was er best wel van onder de indruk. Want het was een soort UNO reverse WINE.

Ik had graag gezien dat ze dit pad verder gingen bewandelen i.p.v. er tussen uit kippen met Hyper-V.

[MSalters]

Hyper-V is tegenwoordig integraal in Windows, geen losse virtualisatie. Dus WSL draait net zoals Windows zelf in een VM.

[beerse]

Ja maar onder msWindows hebben we toch al lang al cygwin? Wat bieden deze coreutils meer dan wat cygwin biedt? Deze cygwin is voor mij de route om een rsync onder msWindows beschikbaar te krijgen.

Natuurlijk is het in de cmd en powershell omgeving nog dichter bij de msWindows beheerders maar daar heeft het toch iets te vaak/veel conflicten met de msDos commando's. Juist de hier boven `find` is daar een heel mooi voorbeeld van waar het (in scripts en dergelijke) fout zal gaan.

Toevoeging: Onder https://github.com/microsoft/coreutils staat een redelijke tabel met conflicten. En er staat ook een verhandeling over /dev/null dat naar "NUL" zou moeten gaan. Dat is NIET zoals het ooit in MSDOS zat: Daar had je "NUL:", met de : aan het einde. Die dubbele punt is om aan te geven dat het een device is, zoals dat toen ook in VMS gebruikelijk was. En waar ook de dubbele punt in de drive-letters vandaan komen. En zo had je ook COM1: t/m COM4: (de seriele poorten) en PRT: (of PRN:) voor de parallele poort en voor de liefhebbers CAS: voor de cassette interface! : Wikipedia: Category:DOS device names

Nu ik er aan denk: de alias constructie van de c-shell (en bash en andere shells) is veel krachtiger dan wat er in PowerShell zit. Wordt die aangepast/uitgebreid?

[Reactie gewijzigd door beerse op 4 juni 2026 16:23]

[xorpd]

Ik heb Cygwin lang gebruikt, maar MinGW is echt stukken sneller en beter. Maar ook MinGW kan in de verte niet tippen aan WSL. En die dubbele punt komt uit CP/M.

[beerse]

Tussen cygwin en MinGW (en andere varianten) zijn vele redenen om voor die implementatie te kiezen.

En of die dubbele punt uit cp/m komt of van vms (vax/vms, open-vms) of andere operating-systemen maakt niet uit: in die jaren (1960 en omstreken) was het gebruikelijk de dubbele punt te gebruiken als scheidingsteken tussen het device en een adres daar binnen of zelfs als device-indicatie. Zo ook het nul-device. in msDos heette dat NUL: en ook de disks die op veel systemen uit die tijd ook meer-letter namen mogen hebben.

Het is unix die is begonnen om alles als een bestand te zien: "zo niet dan toch". En te beginnen met een hiërarchisch filesysteem waaronder alles beschikbaar is met alleen de / als scheidingsteken en geen meta-gegevens in of rond de bestandsnaam.