Windows 11 récupère les coreutils, findutils et grep
Grep party
Mardi soir avait lieu la conférence d’ouverture de la BUILD, la grand-messe annuelle de Microsoft pour les développeurs. Entre autres annonces liées inévitablement à l’IA et aux agents, l’entreprise a mis à disposition des outils que personne n’attendait vraiment : les coreutils pour Windows.
Les coreutils, pour GNU Core Utilities, sont un ensemble logiciel fournissant des commandes standardisées et basées sur Unix pour le shell, autrement dit pour la ligne de commande. Ils contiennent des instructions connues comme chmod pour modifier les permissions d’un fichier, mkdir pour créer un répertoire, rm pour supprimer des fichiers ou encore des outils de manipulation du texte comme printf.
Au cours des derniers mois, les coreutils sont revenus sur le devant de la scène via le projet uutils, une réécriture en Rust des outils. Nous avions d’ailleurs interrogé Sylvestre Ledru, directeur de l’ingénierie chez Mozilla et lead sur le projet, sur lequel les projecteurs s’étaient subitement braqués, Canonical ayant intégré uutils dans Ubuntu 25.10.
Microsoft recompile pour Windows
C’est précisément ce projet que Microsoft a utilisé pour Windows, en compilant uutils pour son propre système. Dans la foulée, Microsoft a d’ailleurs débordé, ajoutant findutils et grep à l’ensemble. Ce dernier est particulièrement connu et utilisé, fournissant un moyen simple et puissant de retrouver du texte. C’est d’ailleurs lui que Microsoft met en avant dans sa courte vidéo de présentation.
Interrogé sur le sujet, Sylvestre Ledru se montre enthousiaste : « Je suis très heureux de voir Microsoft utiliser et mettre en avant uutils, annoncer l’utilisation de nos outils, ainsi que leur contribution de la réécriture de grep en Rust au projet. C’est une belle reconnaissance du travail de la communauté. Leur implication va notamment nous aider à améliorer encore la portabilité sur Windows ».
Les coreutils pour Windows peuvent être récupérés depuis GitHub ou s’installer via la commande WinGet suivante :
winget install Microsoft.CoreutilsMicrosoft prévient que certains outils peuvent entrer en conflit avec ceux déjà présentes dans CMD et PowerShell, un tableau est fourni pour lister les problèmes. À noter que PowerShell doit être installé en version 7.4 minimum.
Commentaires (48)
Abonnez-vous pour prendre part au débat
Déjà abonné ou lecteur ? Se connecter
Cet article est en accès libre, mais il est le produit d'une rédaction qui ne travaille que pour ses lecteurs, sur un média sans pub et sans tracker. Soutenez le journalisme tech de qualité en vous abonnant.
Accédez en illimité aux articles d'un média expert
Profitez d'au moins 1 To de stockage pour vos sauvegardes
Intégrez la communauté et prenez part aux débats
Partagez des articles premium à vos contacts
Abonnez-vousModifié le 3 juin à 10h05
Si vraiment vous tenez à la bataille des fonctionnalités et des chartes graphiques, chacun son environnement de bureau et on en parle plus.
Et pour ne pas perdre la main sur le terrain de la bataille judiciaire, vous pourrez toujours vous écharper sur le nom de l'OS
Le 3 juin à 10h41
Le 3 juin à 11h41
Microsoft a déjà à-peu-près compris que Powershell a le q entre trois chaises, s'ils pouvaint enfin acter que c'est un échec...
Modifié le 3 juin à 12h08
La partie lié aux choix d'implémentation (les trous laissés par les standard) n'est pas neutre du tout.
Le 3 juin à 13h10
Le 3 juin à 15h15
Le 3 juin à 15h36
Oui effectivement c'est un OS différent, au même titre qu'une application grep pour une architecture X64 est différente d'une application grep pour une architecture ARM malgré qu'elles sont toutes deux compilées depuis la même source. Stricto sensu une application compilée avec les infos de debug et l'autre pour la prod sont différentes, pourtant le développeur développe la première et commercialise la seconde, en se basant exclusivement sur une batterie de tests pour vérifier que le comportement des deux instances est identique.
Et c'est bien ce "le comportement est identique" que je simplifie en "même".
J'aime bien quand on comprend l'usage des guillemets d'ironie.
Le 3 juin à 15h51
Le 3 juin à 16h21
Je dis juste les choses suivantes. Attention c'est long parce que c'est parti dans tous les sens...
Point 1. Pour en revenir au sujet du débat, il est pertinent de demander à plusieurs OS différents de partager un socle commun, et que par ailleurs un tel socle commun, tout fragile qu'il soit, existe et s'appelle POSIX. Il n'est donc pas nécessaire d'inventer un quinzième standard.
Point 2. Tout comme pour le bateau de Thésée, il est difficile de tracer une ligne claire et précise sur le fait que deux logiciels sont "les mêmes" ou "différents". Ceci n'a plus rien à voir avec POSIX en tant que norme mais avec la remarque que "le binaire d'un tool [POSIX] ne tourne pas universellement". Oui, la norme POSIX n'impose pas une architecture matérielle ni les conventions d'appel qui en découlent, c'est évident., elle impose juste que "grep" utilise la même syntaxe de regexp et est capable de sélectionner des fichiers texte dans le répertoire courant en utilisant le même pattern glob.
Point 3. Microsoft s'est délibérement écarté des normes POSIX mais poussé par sa base d'utilisateurs de profil développeur, y revient petit à petit.
Modifié le 3 juin à 14h15
Et le support POSIX dans Windows existe depuis longtemps :
On avait jusque là du POSIX.1, les coreutils apportent un peu de POSIX.2.
Modifié le 3 juin à 15h01
Trop subtil comme indice, sans doute.
Avec le lien vers l'article qui dit que le support POSIX dans Windows a été supprimé depuis Windows 8. Merci.
Le 3 juin à 15h33
Ce n'est qu'une description d'interface, pas une implémentation, pas une distribution, pas un OS, ça ne se mêle pas de packaging (la question de départ de ce fil).
La subtilité était un peu épaisse.
Eh oui, le sous-système POSIX du noyau NT a été enlevé lorsqu'il a été remplacé par WSL. Ça n'enlève rien au fait que Windows est compatible POSIX.1 depuis 33 ans, donc si POSIX est une distro Linux universelle, Windows en fait partie depuis 33 ans. Fichtre.
Le 3 juin à 15h39
Le 3 juin à 15h54
Le 3 juin à 17h09
Mais je le fais sur la base d'un constat personnel qui n'est pas dénué de sens.
Le positionnement de l'OS n'a plus rien à voir en 30 ans tout du moins dans le grand public. Longtemps le point central de l'expérience "multimédia", c'est devenu principalement qu'un lanceur de navigateur et une porte d'entrée/sortie via des supports de stockage, de l'impression et de la numérisation.
On est pas mal ici à avoir installé des Zorin OS et autres dans nos familles avec les restrictions de Windows 11, dans mon cas perso les personnes concernées n'ont vu aucun changement en termes d’expérience utilisateur.
Et c'est normal car le PC est essentiellement allumé pour ouvrir le navigateur et imprimer quelques factures. Je peux citer aussi la suite bureautique installée local devenue dispensable avec les suites en ligne.
Mêmes les enjeux de sécurité ont changé, fini le PC vérolé à nettoyer tous les X mois (on citait encore récemment sur un autre fil l'époque des toolbars), maintenant c'est du conseil pour limiter le phishing, et le gros de la prévention est dédié à l'usage téléphone.
En parallèle, on a Valve qui prouve petit à petit qu'une base GNU/Linux peut prendre une position sérieuse dans le jeu vidéo, donc finalement qui peut tout faire.
Même en utilisation pro, on a des propositions sérieuses : QCAD pour le dessin vectoriel, Reaper en station audio, DaVinci Resolve pour la vidéo, Blender pour l'animation.
Chez Apple, y a plus rien de croustillant depuis au moins 10-15 ans sur MacOS, du cosmétique, des transfuges d'iOS et une baisse constante de la qualité du produit fini.
Il lui reste son optimisation liée à la maitrise matérielle mais on sait très bien qu'une distribution linux officiellement supportée pourrait faire le taf quand on voit le projet Asahi Linux.
Et j'ajoute un détail symbolique, l'extinction progressive de la suite iLife vers 2014-2015.
Et ils ont même fait l'exploit de faire fuir les monteurs pro avec Final Cut X, qui se sont barrés ensuite chez Adobe et DaVinci.
La bataille des OS desktop pour le grand public, c'est terminé. Reste la carte de l'IA en dernier recours, résultat Microsoft change de braquet pour seulement commencer à offrir le minimum de ce qu'on attend d'un OS. Toute cette énergie, ce temps et cet argent pour en arriver là....
Tu parles de pertinence dans ton message, je m'interroge justement sur cet aspect concernant l'offre actuelle sur l'OS desktop. Je trouve que ça n'a plus de sens sur le plan stratégie commerciale mais on continue à subir les contraintes inhérentes.
Bref mon point de vue est très certainement perfectible mais pas immuable, c'est tout l'intérêt d'ouvrir le débat.
Le 3 juin à 14h35
Le 3 juin à 17h10
Le 3 juin à 10h06
Le 3 juin à 10h11
Le 3 juin à 16h07
Le 3 juin à 10h40
Le 3 juin à 10h10
Le 3 juin à 11h28
Le 3 juin à 12h36
Legend: ✅ ships and works · ⚠️ ships but conflicts with a built-in · 🛑 not shipped
Ici, après installation, coreutils est au tout début du Path (ce qui donne priorité à ses commandes), mais dans PowerShell, il y a des alias qui passent avant les commandes. Get-Alias donne la liste de tous les alias. On peut les contourner en rajoutant .exe, comme ceci:
ls.exe
Le 3 juin à 10h17
Le 3 juin à 10h37
Surtout que beaucoup de distrib linux deviennent utilisable pour du gaming. Un des derniers intérêts de Windows s'effondre.
Le 3 juin à 10h46
Bientôt on devrat dire GNU/Windows 😜
Le 3 juin à 10h25
Avec la même fiabilité (les fichiers sont vraiment irrécupérables) que sur Linux ?
Le 3 juin à 11h46
En tout cas shred ne fait qu'utiliser les fonctions d'écriture standard et ne se préoccupe pas du fonctionnement sous-jacent :
Le 3 juin à 11h18
Le 3 juin à 11h53
Est-ce que l'une de ces versions serait préférable ?
Modifié le 4 juin à 00h58
winget install uutils.coreutils) sera bien plus complet; le README de la version MS liste beaucoup de commandes non portées car non pertinentes (ça se discute, ils en enlèvent 27) ou en conflit (7).Par contre, le package de MS finasse en fournissant un sort et un find qui peuvent invoquer la version DOS ou la version uutils, suivant les arguments fournis.
Le 3 juin à 11h55
A noter qu'au début des années 2000, Windows faisait 50% du revenu de MS, aujd à peine 10%. Toutefois son revenu absolu a quand même augmenté, 10Mds en 2000 à ~20 en 2025. Après c'est complexe à comparer parce que Windows était surtout stratégique pour tout le verrouillage de l'écosystème notamment la suite office ce qui est bien moins le cas aujourd'hui.
Le 3 juin à 12h18
Mieux vaut tard que jamais, me diras-tu, mais Mark Shuttleworth a tout de même fermé le bug #1 en 2013... quand M$ a loupé le virage du mobile, c'était bien le "début de la fin" !
Heureusement pour eux (surtout pour les employés), ils ont su se convertir en "usine à vendre du cloud" qui est maintenant leur premier métier. Windows en lui-même est de plus en plus totalement secondaire... et même attaqué par Valve sur un des derniers segments historiques : le jeu vidéo !
Le 3 juin à 14h50
Un OS ne rapporte plus d'argent, depuis les smartphones.
Il faut aller chercher les sous sur ce qu'ils font avec. Google et Apple gagnent de l'argent avec les commissions du Store, les devices et les services Cloud pour stocker les vidéos de 2Go qui débordent vite sur des appareils à stockage limité, non extensible ni transférable (tiens donc, la suppression des microSD serait intéressée ?!).
Microsoft le sait depuis un moment, ils ont quasiment rendu l'OS gratuit depuis Windows 10, ils ont tenté le virage du Microsoft Store mais les erreurs de lancement et l'image du "je cherche mon logiciel sur les internets, j'installe mon .EXE et je donne pas un kopek à Microsoft (voir à l'éditeur
Ce qui rapporte de l'argent aujourd'hui, c'est effectivement tout l'écosystème. Et là dessus, sur les entreprises (aka ceux qui ont de l'argent à donner à Microsoft), les stratégies autour de l'écosystème Office/Teams/Azure sont assez bien fichues. C'est forcément plus dur pour le reste quand il y a floppée de solutions gratuites pour le grand public et que le monde entier passe sur des modèles SaaS.
En tout cas, cette année Microsoft part en énorme opération séduction chez les power users, les coreutils et la suite de l'offensive ARM avec une vague de hardware orienté sur les usages "lourds". C'est plutôt une bonne chose, mais est-ce que ce sera suffisant pour stabiliser le bateau...
Le 3 juin à 15h16
Je pense juste que le marché du PC est mature et que microsoft ne peut croitre qu'en captant d'autres marchés émergents comme le cloud mais je ne suis pas sûr pour autant que l'OS soit déficitaire.
Le 3 juin à 16h13
Aujourd'hui tu changes pas d'OS tous les 2 ou 3 ans comme avant, tout comme le parc informatique a tendance à vieillir vu la maturité du hardware. Windows 10 est resté 6 ans, Windows 11 est déjà là depuis 5 ans et n'a pas l'air parti pour être remplacé l'an prochain.
En tant que particulier, mon Windows 10 était une "migration gratuite" depuis Windows 8 qui était déjà une upgrade gratuite depuis Windows 7. Mon PC actuel est de 2020 était livré sous Windows 10 et migré gratuitement sur 11, je ressens pas spécialement le besoin de le changer aujourd'hui sauf pour faire joujou avec les LLM.
Donc je pense vraiment que les revenus de licence ont fondus, pas parce que le prix a baissé, mais parce qu'il se vend beaucoup moins de licences.
Le 8 juin à 05h45
Le changement de version tant pour WS que pour le logiciel n'est pas gratuit (en général).
Le 3 juin à 12h12
En effet, tout d'abord PowerShell, manipule des objets, or les outils bash/shell travaillent sur des flux bruts (texte ou binaire), qui ne sont pas typés, ni structuré. On n'est donc pas vraiment sur des logiques similaires et compatibles.
De plus, comme prévient MS, ces outils vont entrer en conflit avec les alias classique de PowerShell. C'est un coup à flinguer des scripts qui fonctionnaient bien. Je ne sais pas comment ce problème de conflit est géré
Le 4 juin à 09h36
L'idée derrière ce truc n'est pas foncièrement mauvaise, mais la réalisation est catastrophique. La verbosité à faire pâlir COBOL de jalousie, la difficulté à implémenter soi-même des commandes (je me rappelle l'époque où les cmdlets devaient absolument être écrits en Net Framework 3.5 alors que le framework 4 était déjà la norme...) et surtout le nommage des commandes qui rend l'autocomplete quasi impossible, bref un bourbier.
Et quand je dis "pas foncièrement mauvaise" pour parler des objets, c'est plutôt un euphémisme parce que c'est pas franchement bon non plus. Le fait que les commandes s'échangent du texte est tellement plus ouvert ("ouvert" et "Microsoft" dans la même phrase, ça s'appelle un oxymore) que des objets qui ont besoin d'un environnement .Net pour être exploités. Pas de moyen simple de faire communiquer deux processus sur des machines différentes, pas de moyen simple de passer par un fichier intermédiaire plutôt qu'un pipe, pas de moyen simple de faire un traitement par un LLM, et j'en passe.
Au point que même Microsoft s'était félicité qu'un de leurs outils de développement (je ne sais plus lequel, peut-être la version CLI de azure) utilisait "la syntaxe que vous aimez tous" à savoir une commande unique (comme "git" ou "docker") suivie d'une sous-commande, d'une sous-sous-commande et d'arguments. Ils présentaient ça comme une avancée majeure alors que c'est ce que tout le monde fait.
Le 4 juin à 11h01
Nan parce que la communication entre des processus sur des hôtes différents est quand même assez simple à mettre en oeuvre. On peut même exécuter la même commande sur plusieurs hôtes différents de manière transparente.
Bien évidemment qu'on peut remplacer un pipe par un fichier. C'est même la base et c'est la même syntaxe que pour les shells "classiques".
Le seul aspect où je suis d'accord, c'est sur l'aspect verbeux. Mais personnellement, je ne trouve pas cela comme un soucis. Bien au contraire. On peut lire un script powershell même sans être un cador et sans connaitre toutes les commandes par coeur. C'est bien plus difficile quand on enchaine les cat, les awk, sort, tar etc. et qu'il faut connaitre sur le bout des doigts les différentes options (généralement sous forme raccourci) pour comprendre ce que fait un script.
Modifié le 4 juin à 12h30
Et donc l'objet est sérialisé et passe par un stream TCP ? Ou passe par DCOM ?
Et donc l'objet est sérialisé dans le fichier ? Comment
Commande-1 | Commande-2
se traduit-il si je fais à la place
Commande-1 > fichier
Commande-2 < fichier
Notamment, comment l'objet construit par Commande-1 est-il passé à Commande-2 ?
Le 3 juin à 12h27
Apple ne peut que s'en féliciter je crois.
Vu de loin, car mon dernier Windows était XP, j'ai l'impression d'un OS complètement à la ramasse et bordélique au possible.
A un moment il faut repartir de zéro.
Le 3 juin à 13h50
https://m.slashdot.org/story/454939
Basé sur du fedora et pour du serveur que pour le moment...
Le 4 juin à 15h05
Windows n'a plus rien de XP.
Ayant le même genre de vue sur Linux que toi sur Windows, c'est Linux pour lequel j'ai l'impression d'un OS inutilement compliqué techniquement et en pratique. (là ou Windows est user-friendly jusqu'aux options)
Évidemment, je sais que j'ai tord.
Le 4 juin à 16h07
Note que je parlais sous le capot, techniquement quoi. Linux est simplissime en comparaisons.
Mais pour les interface user c'est sur que c'est aussi grandement une question d’habitudes.
Le 3 juin à 15h46
Combien de fois j'ai fait un dig domain.com @ns.domain.net dans CMD et râlé parce que ça marchait pas
Par contre ajouter grep, quel bonheur
Le 8 juin à 06h02
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?