GNU Binutils sous Windows : un réflexe devenu inutile ?
Ce que Windows sait déjà faire nativement, sans rien installer
Publié le
Un réflexe hérité, pas toujours interrogé
J'utilise Linux comme environnement de travail depuis 1995. Et je croise régulièrement des personnes qui, sur un poste Windows, installent Git Bash, les GNU coreutils compilés pour Win32, ou un sous-ensemble de MSYS, uniquement pour retrouver ls, grep ou cat. C'est un réflexe compréhensible : ces commandes font partie du muscle-memory de quiconque a appris l'informatique via Unix. Mais un réflexe n'est pas toujours une décision définitive — et c'est justement ce qui m'intéresse ici.
Windows n'a jamais été dépourvu d'outils en ligne de commande. Il en a simplement deux générations superposées : l'invite de commandes historique (cmd.exe), héritière directe de MS-DOS, et PowerShell, bien plus récent, pensé dès le départ comme un shell orienté objets plutôt que flux de texte. À eux deux, ils couvrent aujourd'hui la quasi-totalité des usages courants des GNU Binutils.
Le tableau de correspondance
Voici les équivalences les plus utiles au quotidien, entre commande GNU/Unix, équivalent natif en invite de commandes, et équivalent natif en PowerShell (souvent lui-même un alias vers une cmdlet .NET plus riche).
| GNU / Unix | cmd.exe | PowerShell |
|---|---|---|
ls | dir | Get-ChildItem |
cat | type | Get-Content |
cp | copy | Copy-Item |
mv | move | Move-Item |
rm | del / erase | Remove-Item |
mkdir | mkdir / md | New-Item -ItemType Directory |
rmdir | rmdir / rd | Remove-Item -Recurse |
pwd | cd (sans argument) | Get-Location |
grep | findstr | Select-String |
find | where / forfiles | Get-ChildItem -Recurse |
diff | fc | Compare-Object |
sort | sort | Sort-Object |
head / tail | more (partiel) | Get-Content -Head / -Tail |
wc | — | Measure-Object |
ln | mklink | New-Item -ItemType SymbolicLink |
chmod / chown | icacls / takeown | Set-Acl |
ps | tasklist | Get-Process |
kill | taskkill | Stop-Process |
env | set | Get-ChildItem Env: |
which | where | Get-Command |
curl | curl (natif depuis 2018) | Invoke-WebRequest |
ping / traceroute | ping / tracert | idem |
Ce tableau n'est pas exhaustif — la liste complète des commandes Windows tient sur plusieurs centaines d'entrées dans la documentation officielle Microsoft — mais il couvre déjà largement ce que quelqu'un va chercher dans les GNU Binutils pour un usage quotidien de navigation, de manipulation de fichiers ou d'inspection système.
Ce que ça change, vu d'une architecture
Ce qui m'intéresse dans ce constat, ce n'est pas la commande en elle-même, mais ce qu'elle raconte du système dans lequel elle s'exécute. Installer une couche GNU par-dessus Windows, c'est ajouter une surface : des binaires supplémentaires à maintenir (comme la CVE-2025-69651), une variable PATH à gérer, des comportements de shell à synchroniser entre deux mondes qui ne partagent ni le même modèle de fichiers (chemins, séparateurs, sensibilité à la casse), ni le même modèle de sécurité (permissions POSIX simulées vs ACL NTFS réelles). Chaque couche ajoutée est un point de divergence potentiel entre ce qu'on croit exécuter et ce qui s'exécute réellement.
PowerShell change en plus la nature du problème : là où les GNU Binutils font circuler du texte brut entre commandes (avec tout ce que ça implique de parsing fragile), PowerShell fait circuler des objets .NET typés. Get-Process | Sort-Object CPU ne parse rien, il trie des objets Process sur une propriété. C'est un paradigme différent de celui d'Unix, pas un sous-ensemble appauvri, et c'est précisément pour ça que le réflexe "reproduire l'environnement Linux à l'identique" passe à côté de ce que Windows propose réellement aujourd'hui.
Ce que le tableau ne dit pas
Par honnêteté, il faut aussi dire où l'équivalence natif Windows s'arrête. sed et awk n'ont pas de vrai équivalent en une commande cmd.exe ; il faut du PowerShell plus verbeux (ou une expression régulière dans Select-String) pour approcher leur puissance de traitement de texte en flux. Un script bash existant, avec ses redirections et son set -e, ne se traduit pas terme à terme en batch. Et si le besoin réel est de faire tourner un environnement Linux complet — pas juste quelques commandes isolées — la bonne réponse n'est de toute façon plus d'empiler des binaires GNU par-dessus Windows : c'est WSL2, qui fait tourner un vrai noyau Linux, avec une intégration native au système de fichiers Windows. C'est une solution différente du problème que les GNU Binutils isolés essayaient de résoudre à moitié.
En pratique
Pour un usage occasionnel de terminal sous Windows (navigation, recherche de texte, gestion de processus, scripts d'automatisation simples) les commandes natives suffisent, sans rien installer, sans surface supplémentaire, sans divergence de comportement à surveiller. Le réflexe GNU Binutils garde du sens dans deux cas précis : maintenir un script bash existant qu'on ne veut pas réécrire, ou vouloir un comportement strictement identique entre Linux et Windows dans un pipeline CI multiplateforme. En dehors de ces deux cas, c'est une dépendance de plus pour un gain de moins en moins évident.