En dépit de sa numérotation, cette version 1.16 est majeure, tant les nouveautés sont nombreuses. Les utilisateurs peuvent par exemple personnaliser complètement les fenêtres, y compris le fond, les onglets, les barres d’onglets, etc.
De nouvelles couleurs de personnalisation ont été ajoutées et le Terminal se lance désormais en thème sombre par défaut, sans plus se baser sur le système.
Le nouveau moteur de rendu, qui avait été introduit en préversion dans la 1.13, est finalisé et utilisé par défaut. Il offre de meilleures performances, supporte davantage de pixel shaders, le gras ainsi que les lignes pour les textes barrés, soulignés et hyperliens. En cas d'accélération graphique absente, le rendu logiciel est également plus véloce.
Attention, s’agissant d’une préversion, des bugs peuvent survenir.
- Télécharger Terminal 1.16 Preview (Microsoft Store)
Commentaires (38)
#1
Bonnes nouvelles tout ça ! Vivement la release finale
#2
#3
#4
il y a un truc que je capte pas, j’ai Terminal et Powershell.
C’est quoi la différence sachant que quand je lance terminal, il me dit qu’il est sous PowerShell
je comprend pas la dif entre les 2 , à part l’aspect visuel
#4.1
Powershell est un shell, une interface système en ligne de commande (c’est en très gros un interpréteur d’un langage). Cependant, quand tu lances “Windows Powershell” tu lances un terminal, un logiciel permettant d’utiliser un shell. Par exemple “Invité de commande” est un terminal permettant de lancer un shell Batch (DOS). L’application “Terminal” est aussi un terminal qui permet de lancer différent shell. Par défaut, il ouvre un onglet avec Powershell, mais tu peux en ouvrir un en Batch et même un bash/shell (linux) via WSL (mais du coup, tu peux surement lancer d’autre shell linux comme csh&co).
En gros, Terminal est une application de “terminal” générique modernisé avec des onglets et une grande personnalisation.
#4.3
Merci beaucoup
#4.4
du coup chaque shell à son propre langage, terminologie ?
on peut faire à peu prêt les mêmes choses dans tous les shell mais les invit de commandes pour faire ces choses diffère d’un shell à l’autre ?
Ma seule expérience en shell c’était d’installer des jeux en DOS sur des 490dx et du winget sur PowerShell…..
#4.6
Oui. Par exemple dans un shell ms-dos tu vas taper “dir” pour avoir la liste des fichiers du répertoire courant, tandis que dans un bash ce sera “ls” pour faire la même chose. Et en powershell c’est encore une autre commande dont le détail m’échappe (Get-Files ?).
Beaucoup de shells offrent cependant des alias, donc taper “dir” dans ms-dos va faire dir, dans un bash ce sera un alias de ls, et dans Powershell ce sera un alias de Get-Files.
#4.8
Oui, et ça va même plus loin car souvent le shell étant pensé en même temps que l’OS, il suit un logique lié à l’OS. Par exemple Bash/shell (linux) est centré sur la manipulation de flux non typé (c’est vaguement du texte). Pour linux, tout est un flux et on ne fait que brancher des flux d’un outils vers un autre. Au contraire, Windows NT et Powershell sont centré sur la manipulation d’objet/map. C’est donc quelque chose de très différent. Et on comprend du coup que non, Bash/shell n’est pas optimal avec Windows.
Comme je viens de le dire, Bash, c’est bien pour linux car ça colle avec son paradigme de traitement de flux non typés, mais Windows NT, lui c’est de l’objet typé qu’il fait donc absolument pas du Bash.
Ensuite, le noms des commandes (Cmdlets) Powershell suivent une logique stricte de nommage qui les rendent facile à comprendre et plus facile à trouver. En effet, elle commencent toutes par un verbe selon une liste suivit d’un nom qui est libre. Tu remarquera d’ailleurs que dans la liste de verbe, il y a quelque chose entre parenthèse, ce sont les abréviation des verbes pour les alias.
En effet Powershell vient avec un liste d’alias assez importantes (accessible via le cmdlet
Get-Aliasou l’aliasgal). Cette liste peut être diviser en 2 familles. La première, c’est celle qui suivent une convention de nommageverbe abrégé+nom abrégé(Get->getAlias->al, doncGet-Aliasc’estgal). Donc là encore c’est facile à comprendre. La seconde famille est celle qui va suivre l’héritage et les habitudes. En faite, beaucoup de nom de commande courante en Batch et un Bash ont un alias en Powershell. Par exemple le cmdletGet-ChildItemqui, utilisé ainsi, va lister le contenu du dossier courant possède l’aliasdirde Batch et l’aliaslsde Bash en plus de l’aliasgci.En faite les alias de
Set-Locationsont :cd,chdiretsl, la dernière étant l’alias “powershell”.#4.9
Merci beaucoup. Je vais devoir faire du PS, j’avais le même ressenti que 33A20158-2813-4F0D-9D4A-FD05E2C42E48.
Ton lien + l’explication, ça va m’aider!
#4.11
Tiens, un petit truc qui pourra te servir :
Qui permet de rapidement lister les alias des paramètres de
MaCmdLet. Ca permet de récupérer en gros la version “short” des paramètres. Après j’avoue que là dessus, ça pèche un peu et l’accumulation de paramètre sans alias est très vite verbeux. Je trouve un peu dommage que l’alias des paramètre ne soit pas aussi poussé. Sinon, dans tous les cas, tu tabs à tout va, ça remplie le reste.Tu peux même ajouter ça à ton profile (en gros le .bashrc de Powershell)
tu tapes :
(j’ai pris notepad car tout le monde l’a, mais utilise ton éditeur préféré)
tu colles ça :
tu enregistres et tu relances Powershell.
#4.10
Merci, très intéressant
#4.5
Microsoft aurai peut être du partir d’un Nix modifié comme l’a fait Apple. Ça aurait fait moins usine à gaz
#4.7
Déjà s’ils n’avaient pas pondu powershell et réutilisé bash plutôt ? Mais qui est l’andouille qui a trouvé que taper Change-The-Current-Directory-To –Target=“x’ c’était mieux que cd x
#4.2
Une explication (en anglais) par Scott Hanselman pour compléter la réponse de tazvld
https://www.hanselman.com/blog/whats-the-difference-between-a-console-a-terminal-and-a-shell
#5
On m’avait dit que Microsoft ferait enfin un vrai terminal, mais sans pouvoir s’empêcher d’un faire une usine à gaz… qq années après les bureaux virtuels, toujours merdiques comparés à l’original!!!
#6
Nannnnn tu déconnes c’est pas vrai hein ? … Hein ?
#6.1
Non, c’est une blague. En vrai c’est Set-Location, et tu peux utiliser le raccourci cd comme sous bash
#6.2
De fait j’exagère comme à mon habitude, mais c’est quand-même verbeux dès que tu veux faire quelque chose d’un peu complexe comparé à tout ce qui existe.
#7
merci
#8
A noter que le Terminal est maintenant par défaut pour tout le système dans les builds insider Dev.
Du coup, quand on tape cmd, ça ouvre le nouveau terminal, même chose si c’est une application qui appelle un script .bat ou toute commande shell.
#9
C’est pour cette raison que je déteste PS : des noms à rallonge tarabiscotés.
Qu’est-ce qu’on est bien sur bash !
Il m’arrive d’ailleurs très souvent de reprendre les commandes Linux sous Windows sans faire gaffe
J’ai même osé une fois un apt update 
C’est pire : Get-ChildItem
Je sais pas ce qu’ils fument chez MS, mais c’est de la bonne on dirait 
#10
Je pense un peu la même chose.
C’est même pas un
ton commentaire.
MS a fait pas mal de progrès depuis l’époque Ballmer (et avant), mais ça reste quand même particulier.
#11
Les bureaux virtuels existent depuis Windows XP via les PowerToys.
#12
Un hack bourré de bugs à l’utilisation…
#13
Ah mais c’est tellement vrai, j’ai jamais compris pourquoi les commandes simples de bash n’ont pas été reprises, et ont été remplacé par des commandes de 12 km impossible à se rappeler, tellement impossible d’ailleurs qu’ils ont fait des alias de commandes bash les plus utilisées….
Ou comme la simple connerie qu’on ne peut pas ouvrir un fichier qui n’existe pas pour le créer, il faut créer le fichier d’abord et l’ouvrir ensuite avec 2 commandes différentes… alors que n’importe qu’elle commande bash vi, nano, créer et ouvre le fichier en même temps…
#14
Ce qui est rigolo, c’est que les “détracteurs” de PowerShell sont… les utilisateurs de bash ! (et compatible).
Cela a déjà été dit, donc tant pis pour la répétition, mais PowerShell n’est pas bash, et ne repose pas du tout sur le même paradigme. Bash, c’est la notion de flux. PowerShell, c’est la notion d’objet.
Oui, le nom des CmdLets “pue” quand on est habitué aux noms courts. Idem pour les options à rallonge. Maintenant que ça a été dit, les avantages de PowerShell :
Oui, PowerShell casse les habitudes, donc, pour ceux qui ont l’habitude de Bash, c’est “difficile / nul / tout ce que vous voulez” . Mais PowerShell est tellement puissant quand on s’y intéresse un temps soit peu et qu’on surmonte cette résistance au changement…
#15
Non, je suis détracteur de PowerShell parce que je suis programmeur. Et le programmeur que je suis se désespère de voir un concept puissant (les objets) martyrisé par une syntaxe à la con. Il existe déjà une syntaxe pratique pour manipuler des objets, mais elle est complexifiée à mort parce que Powershell ne sait pas sur quel pied danser et tente de montrer des objets en les traitant à la ligne de commande comme s’il s’agissait de simple collections de records.
On se ramasse des noms de cmdlets à dormir à la rue parce que notamment la notation pipe ne sait pas correctement gérer le polymorphisme.
Bah voui, alors pourquoi ne pas une fois pour toutes proposer un langage de programmation cohérent qui permet tout ? Pourquoi devoir jongler d’un côté avec la notation “pipe” et d’un autre la notation pointée pour extraire les données ?
Voilà, c’est ce non-aboutissement typiquement microsoftien que je reproche à Powershell.
#16
Que reproches-tu à la syntaxe ? La syntaxe “classique” pointée est utilisable.
Il existe des syntaxes complexes pour gérer les cas complexes, notamment lorsqu’il y a des collections, où la notation pointée est insuffisante.
C’est-à-dire ? Car je ne vois pas du tout de quel problème tu parles…
Peut-être parce que les deux ne font pas la même chose ? Entre extraction et manipulation, il y a une énorme différence. Une extraction est un cas particulier de manipulation. Une manipulation n’est pas forcément une extraction.
Un pipe sert à connecter deux manipulations ensembles (transmettre la sortie standard d’un programme vers l’entrée standard d’un autre). La notation pointée permet d’accéder directement aux propriétés et méthodes d’un objet.
J’ai l’impression de lire les propos d’une personne restée dans les années 90-2000. Microsoft a quand même bien changé et parler de non-aboutissement me semble plus refléter d’un aveuglement idéologique que d’une réelle argumentation…
#16.1
Et pour compléter une argumentation déjà longue,
https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
Que je traduis très librement par
#17
Pourquoi la notation pointée serait-elle insuffisante ? En C# tu as de collections et tu les manipules en notation pointée via les extensions Linq, et rien ne t’empêche d’ajouter des extensions pour exécuter une même fonction sur tous les éléments (je pourrais écrire une fonction Cos qui s’applique sur un itérable de flottants et renvoie un itérable de flottants qui sont les cosinus des éléments…)
Pourquoi gérer le même problème par deux méthodes différentes ? Pourquoi ne pas ajouter les petits détails qui manquent à la syntaxe C# pour la rendre encore plus “fluent” sur les collections ?
La notation pipe permet de relier entre eux deux cmdlets qui se veulent indépendants, mais en pratique le cmdlet récepteur doit être un minimum au courant de ce qu’il reçoit.
Imaginons que j’aie une commande Get-Machins (qui renvoie des machins) et Get-Bazars (qui renvoient des bazars) et que ces deux choses soient écrits par des personnes indépendantes. Imaginons maintenant que les machins et les bazars puissent tous deux être frobulés. Avec une notation pipe, je vais être obligé d’avoir deux cmdlets avec des noms différents Frobulate-Machins et Frobulate-Bazars :
tandis qu’avec une notation pointée, le typage va désambiguer naturellement les deux fonctions malgré qu’elles ont le même nom. Je ne risque pas de me tromper en appliquant la mauvaise fonction de frobulation. Je n’ai pas besoin de répéter le type.
Non, frustration. À chaque problème similaire, chaque produit basé sur .Net vient avec une solution ad-hoc plutôt que d’une fois pour toutes exploiter un tronc commun. Microsoft possède une solution simple propre et efficace à un nombre incroyable de cas et s’obstine à ne pas l’utiliser: c#
C# possède une syntaxe homogène qui permet d’exprimer des conditions, des boucles, des filtres, des extractions, des transformations de tous types de données possibles et imaginables.
Ben non, pour les fichiers csproj on réinvente des tags xml conditionnels, des ItemGroups, au lieu d’écrire
if (Target.Platform == Platforms.X64) {
}
qui serait 1000 fois plus lisible.
Ben, non, pareil pour Powershell, avec des syntaxes ad-hoc pour effectuer des transformations un peu poussées. Si en c# je veux déplacer tous les fichiers d’un répertoire dans un sous-répertoire en fonction de l’extension, je pourrais écrire :
CurrentDirectory.Files().MoveTo(f => CurrentDirectory.Subdirectory(f.Extension.TrimStart(“.”))
Il “suffit” ensuite de peaufiner un peu du “syntactic sugar” pour éviter de devoir écrire “currentdirectory” et l’argument de la lambda, et on arriverait facilement à :
Files().MoveTo(Subdirectory($.Extension.TrimStart(“.”))
Ben en syntaxe pipe de Powershell, je n’ose pas imaginer comment on peut bien faire. Ha oui, merci SuperUser.com :
\(extensions = (Get-ChildItem -Path \)sourceFolder -File | Group-Object {\(_.Extension.TrimStart(".")}).Name
foreach (\)ext in $extensions) {
}
Euh… “Join-Path -Path -ChildPath” ??? Honnêtement ? C’est de l’aveuglement que trouver ça ridiculement verbeux et inabouti ???
#18
Linq sont des méthodes d’extensions. Du sucre syntaxique pour éviter de devoir écrire des trucs du style Math.Cos(maCollection) et pouvoir faire maCollection.Cos().
Sauf que :
Tu veux sans doute dire PowerShell ;) Car c’est déjà pas mal fluide en C# avec Linq et les méthodes d’extensions. Et en C#, les méthodes d’extensions sont pleines de petits pièges (traitement différent du null, attention à la surcharge, impossible à utiliser en cas d’ambiguïté, etc…)
Alors, j’ai envie de dire oui et non (réponse de Normand, mais il faut m’excuser, je le suis :p). Je pense que nos divergences d’opinions viennent des attentes différentes que nous avons l’un l’autre d’un langage de script. Comme PowerShell se rapproche énormément de C#, tu attends d’avoir un comportement à la C#. Comme PowerShell est un langage de script, je m’attends à ce qu’il soit facile à utiliser (et potentiellement, avec le paradigme objet, plus simple que bash).
Le problème que tu soulèves se pose également en Bash. Et même en C# tu ne pourras pas avoir la solution aussi simple (sauf à définir explicitement une méthode d’extension sur des collections de type Bazar et Machin) et il faudra utiliser du Linq (Select) et un delegate ou une lamba.
Tu reproches au fichier csproj de ne pas être en C#. Mais du coup, les fichiers vbproj il faut les écrire en quoi ? Et les fsproj ? Et les vcxproj ? Pourquoi privilégier le C# à un autre langage ?
Le XML, qu’on l’aime ou ne l’aime pas, permet d’harmoniser la structure des fichiers projets au sein de Visual Studio / Visual Studio Code. C’est un choix. Tu n’es pas d’accord avec, c’est ton droit. Mais dire que c’est de l’obstination, là je ne suis pas d’accord. Les fichiers projet, qu’ils soient pour du .Net ou non, ont aujourd’hui TOUS la même forme.
Oui, c’est de l’aveuglement, car la commande PowerShell pour y arriver est extrêmement simple par rapport à ce que tu as proposé :
Get-ChildItem \(sourceFolder -File | ForEach-Object -Process {Move-Item -WhatIf -Path \).FullName -Destination “\(sourceFolder/\)($.Extension.TrimStart(”.“))”}
Et la versions répertoire courant (puisque c’est avec cette version que tu compares la version C# :
Get-ChildItem . -File | ForEach-Object -Process {Move-Item -WhatIf -Path \(_.FullName -Destination \)_.Extension.TrimStart(“.”)}
J’ai juste mis un -WhatIf pour que cela ne déplace pas les fichiers mais que cela affiche ce qui va être fait.
De plus, cette commande, quiconque avec de légère connaissance en programmation devinera assez facilement ce qu’elle fait simplement en la lisant, justement parce que c’est verbeux.
Et maintenant, je t’invite à penser la même chose en bash. Cela risque d’être très rigolo également ! Et par contre, complètement abscons, car il faut connaître le positionnement des paramètres, les syntaxes raccourci des options, etc… bref, une relecture difficile
#18.1
On est d’accord qu’on n’a pas les mêmes attentes. Je vais m’autoriser à continuer à exposer les miennes.
Exactement ! La contrainte de pouvoir utiliser C# dans un REPL dans le but essentiel de configurer un Windows aurait eu des effets bénéfiques sur la syntaxe du langage, pour le rendre encore plus fluide.
Par exemple autoriser à préfixer un nom de variable par $ pour pouvoir l’assigner et la réassigner sans la déclarer. Même changer son type…
Par exemple pouvoir utiliser une variable nommée \( dans une expression, qui transformerait cette expression en lambda sur la variable \) - En linq pouvoir faire
au lieu de
.Where (f => f.size > 0)
Contrairement à ce que j’ai pu laisser penser, je ne suis pas particulièrement amoureux de la syntaxe bash non plus, là aussi c’est un foutoir sans nom, comme tous les langages de script shell en général évidemment.
Je me désole que l’intention de Powershell était de donner un coup de pied dans la fourmilière, mais qu’on s’est contenté d’un dépoussiérage minimal. Tiens, par exemple, dans ton exemple “simple” justement, le répertoire destination est construit en concaténant des strings, le truc universellement reconnu comme étant une source d’arrachage de cheveux (dois-je rappeler ces Windows qui cessent de marcher parce qu’un batch a malencontreusement créé un fichier “c:\Program” en voulant créer un fichier dans “c:\Program Files\” ???).
Toutes ces choses ancillaires sont clarifiées et inambiguës dans la version C#. C’est dommage de s’arrêter à la moitié du chemin dans l’objectification. En pratique tu manipules certes des objets, mais toujours en passant des strings comme paramètres ; c’est ballot, c’est justement là que les langages de script contiennent le plus de bugs en cas de paramètres vides ou contenant des espaces. Ca aurait été l’occasion de faire ça proprement.
Je ne privilégie pas C# à un autre langage. Je privilégie un vrai langage de programmation, n’importe lequel à du XML dans lequel on a fait entrer des structures conditionnelles au forceps.
Tout ce que tu dis de XML (et qui est très juste, évidemment) serait tout aussi valable si on avait choisi un autre langage structurant. Un gars qui écrit sont projet en F# doit de toute façon “comprendre” la structuration de son fichier projet qui est déjà dans un autre langage que celui qu’il utilise pour le code, donc en pratique ça ne change rien. Et puis j’ai proposé C#, pas APL ou Malbolge
#19
Pas de souci. L’échange est constructif donc ça me va ;)
Ca par contre, c’est une idée qui me plait
Souhaites-tu le proposer comme idée sur le dépôt dédié à ça ? Ou puis-je le faire ?
Si cela peut te rassurer, je pense qu’il sera bientôt possible de pouvoir utiliser C# directement en tant que langage de script. Avec .NET 6, on a vu apparaitre les “top-levels statements”, permettant d’écrire un hello world en une seule ligne.
Le pas n’est pas très loin pour que l’on puisse se servir de C# en tant que langage de script.
Roh, XML n’est pas un langage de programmation ? Heureusement qu’il y a HTML et CSS pour rattraper le coup (ironie inside
)
Je comprends également ton point de vue (et contrairement à ce que tu pourrais laisser croire mon précédent commentaire, je suis pour aussi !). Et comme je le disais, avec les top-levels statements, ce genre de chose sera plus facilement réalisable à l’avenir.
Maintenant, on peut reprocher beaucoup de chose à Microsoft, mais ils font un travail assez incroyable sur la compatibilité. Donc, à mon avis, à cause de cela, cela ne sera pas demain la veille que cela changera
Le C#iste que je suis approuve. Mais je préférerai quand même du brainfuck (ou du Ook histoire de pimenter les choses et que cela soit plus verbeux
)
#20
C’était mon intention et je suis ravi que tu le prennes ainsi.
Affirmatif. Ce ne serait évidemment disponible que dans le REPL (ou via une option dans le csproj, comme les types nullables - désactivé par défaut évidemment). Ne pas pouvoir redéfinir une variable ou fonction dans le REPL quand on s’est trompé serait une limitation trop forte…
Vas-y. Je ne suis pas coutumier de la procédure (envoie-moi le lien de l’item pour que je puisse monitorer l’avancement)
Je suis fan des top level statements en effet, et j’ai beaucoup d’utilitaires que j’écris pour être utilisés par un dotnet run.
Pas mieux. Ah si, YAML qui a les mêmes soucis…
Je tape sur le clou: Powershell n’avait aucune compatibilité à maintenir, c’était une occasion en or.
Personnellement j’avais opté pour COBOL.
#21
Pas de souci. Je vais le faire et je t’enverrai le lien ;)
PowerShell existe quand même depuis 2006. Et à cette époque, C# et .Net (surtout la version Core qui n’existait tout simplement pas) n’avait absolument pas la renommée qu’ils ont aujourd’hui. Je me demande même si VB.Net n’était pas plus populaire à l’époque !
Victoire par KO pour le COBOL niveau verbosité
#22
Finalement, je n’ai rien à faire. Quelqu’un à déjà proposé l’idée dès 2017. Il y a eu des commentaires jusqu’en 2020.
#22.1
Bon, ben un coup dans l’eau alors… De mon côté j’essayais de permettre une notation pipe :
en essayant de redéfinir l’opérateur | :
Mais il y a tellement de restrictions sur la définition d’opérateurs que c’est un échec sur toute la ligne. Je devrais essayer en C++ qui est beaucoup plus permissif avec les opérateurs.