Microsoft lance une nouvelle interface de ligne de commande pour Windows, baptisée Windows Terminal. Elle est conçu pour être l’emplacement central pour l’accès à des environnements tels que PowerShell, Cmd et Windows Subsystem for Linux (WSL). Microsoft ajoute la prise en charge de plusieurs onglets aux côtés de la personnalisation pour les développeurs qui souhaitent peaufiner l'application Terminal. Les développeurs pourront donc personnaliser Windows Terminal de différentes manières et lui ajouter des thèmes ainsi que des extensions.
Windows Terminal prendra également en charge le rendu de texte emoji et le rendu basé sur un processeur graphique. Windows Terminal va donc offrir un rendu plus rapide du texte accéléré par le GPU et des polices « riches en emoji », car tout aujourd’hui tend à prendre en charge les émojis, et ceux-ci contribueront à alléger l'expérience utilisateur en ligne de commande. Plus important encore, Windows Terminal prend également en charge les raccourcis, les onglets, les fenêtres détachables et les thèmes, ainsi que les extensions. Il prendra également en charge de manière native les polices Unicode et East Asian.
Microsoft a dévoilé la nouvelle application Windows Terminal au cours de l’édition 2019 de la conférence Build dédiée aux développeurs. L'idée ici, selon Microsoft, est de « rehausser l'expérience utilisateur en ligne de commande sous Windows ».
Windows Terminal, qui est déjà disponible en préversion, est prévu pour être lancé de manière générale à la mi-juin et promet d'être une mise à jour majeure de l'invite de commandes Windows et de l'expérience PowerShell existantes. En effet, il semble que Terminal deviendra essentiellement l’environnement par défaut pour les utilisateurs de PowerShell, Cmd et Windows Subsystem for Linux.
En parlant de WSL, une couche de compatibilité permettant d’exécuter de manière native des exécutables binaires Linux sous Windows, Microsoft travaille sur la prochaine version. WSL 2 est basé sur un noyau Linux 4.19 bientôt disponible sous Windows. Ce noyau utilise une technologie conçue pour Azure. Dans les deux cas, il est utile de réduire le temps de démarrage de Linux et de rationaliser l'utilisation de la mémoire. En fait, Microsoft promet aux développeurs « deux fois plus de vitesse pour les opérations lourdes sur les systèmes de fichiers, telles que l'installation de Node Package Manager ». WSL 2 prend également en charge l'exécution native des conteneurs Linux Docker, de sorte que les ordinateurs virtuels ne sont plus nécessaires.
Comme Windows Terminal, WSL 2 arriveront tous les deux à la mi-juin.
Vaut mieux tard que jamais (ça fait juste ~15 ans que l'on a ça sous linux)
Heu... non, il y'a 15 ans sous linux, Settings affichais une GUI pour les réglages les plus courants (couleurs, transparence, image de fond,...). On touchais les fichiers de confs du terminal rarement.
Ici sa ouvre juste un éditeur Json, à la méthode de VS Code. Flemme/20
si il y a bien un domaine où personne ne sera jamais d'accord c'est bien les formats de stockage.
en plus pourquoi, ici, se compliquer la tâche avec des formats de fichier pénibles à parser, à la première lecture un bête fichier ini est amplement suffisant, et le parser plutôt trivial à écrire :
mais bon, ça doit pas faire suffisamment moderne, donc on se complique la vie.
(et même si on peut vouloir plusieurs combinaisons de touches par commande, on peut très bien définir une syntaxe pour en mettre plusieurs à la suite)
ps: pas que json, xml, yaml, autres n'ont pas d'utilité, mais ils ont comme principal avantage de pouvoir stocker des données structurées. dès lors que la structuration des données est pratiquement inexistante, pas la peine de se compliquer la vie.
de plus pour stocker des structures, il faut souvent une syntaxe bien particulière, pas forcément adaptée à être écrite facilement par un humain ; d'où le fait d'avoir un truc le plus simple possible à mon avis.
mapper un objet depuis un fichier json, c'est pas magique, il a fallu que quelqu'un l'écrive ce code, rien n'empêche donc d'avoir strictement la même chose pour un fichier ini en fait.
en plus pourquoi, ici, se compliquer la tâche avec des formats de fichier pénibles à parser, à la première lecture un bête fichier ini est amplement suffisant, et le parser plutôt trivial à écrire
Parce que le format ini n'a pas été normalisé et chacun fait ce qu'il veut ou suit Microsoft.
Par exemple, la gestion des espaces. Est-ce que tu les autorises entre le début de ligne et la clef ? Est-ce que tu les autorises entre la clef et le = ? Est-ce que tu les autorises entre le = et la valeur ? Est-ce que tu les autorises entre la valeur et la fin de ligne ?
Le seul gros point noir du json c'est le non support de l'Unicode
Et l'autre point gênant, c'est le manque de commentaires (soit on rajoute des clefs bidons, soit on empile les même clefs - la majorité des parsers prennent la dernière valeur et ignorent les autres)
Membre extrêmement actif https://www.developpez.com
Le 23/06/2019 à 22:20
Ok il y a un terminal, why not... Mais quid du shell ? (oui parce que pour les néophyte c'est pas la même chose).
Genre là niveau shell on est toujours limité à cmd (celui de base), powershell, et depuis récemment WSL (perso j'ai pas été convaincu, ne serait-ce que par le fait qu'on se retrouve dans un container qui fait que, si ma mémoire est bonne, WSL a son propre système de fichier, qui peut accéder à celui de windows, mais on ne peut pas accéder au système de fichier de wsl depuis par exemple explorer...)
Donc perso je continue sur ma lancée avec conemu et zsh
Genre là niveau shell on est toujours limité à cmd (celui de base), powershell, et depuis récemment WSL (perso j'ai pas été convaincu, ne serait-ce que par le fait qu'on se retrouve dans un container qui fait que, si ma mémoire est bonne, WSL a son propre système de fichier, qui peut accéder à celui de windows, mais on ne peut pas accéder au système de fichier de wsl depuis par exemple explorer...)
si il y a bien un domaine où personne ne sera jamais d'accord c'est bien les formats de stockage.
en plus pourquoi, ici, se compliquer la tâche avec des formats de fichier pénibles à parser, à la première lecture un bête fichier ini est amplement suffisant, et le parser plutôt trivial à écrire :
mais bon, ça doit pas faire suffisamment moderne, donc on se complique la vie.
(et même si on peut vouloir plusieurs combinaisons de touches par commande, on peut très bien définir une syntaxe pour en mettre plusieurs à la suite)
ps: pas que json, xml, yaml, autres n'ont pas d'utilité, mais ils ont comme principal avantage de pouvoir stocker des données structurées. dès lors que la structuration des données est pratiquement inexistante, pas la peine de se compliquer la vie.
de plus pour stocker des structures, il faut souvent une syntaxe bien particulière, pas forcément adaptée à être écrite facilement par un humain ; d'où le fait d'avoir un truc le plus simple possible à mon avis.
La différence est que tu peux directement mapper un objet avec son pendant json, alors qu'un ini c'est relou en fait.
Je n'ai pas regardé le code mais ils font surement un truc aussi simple que Json.Deserialize<ConfigurationObject>(chemin de fichier) pis basta.
Microsoft lance une nouvelle interface de ligne de commande pour Windows, baptisée Windows Terminal. Elle est conçu pour être l’emplacement central pour l’accès à des environnements tels que PowerShell, Cmd et Windows Subsystem for Linux (WSL). Microsoft ajoute la prise en charge de plusieurs onglets aux côtés de la personnalisation pour les développeurs qui souhaitent peaufiner l'application Terminal. Les développeurs pourront donc personnaliser Windows Terminal de différentes manières et lui ajouter des thèmes ainsi que des extensions.
Qu'en pensez-vous ?
Envoyé par Refuznik
et chacun fait ce qu'il veut ou suit Microsoft.