Le terminal est un truc merveilleux une fois qu'on sait l'utiliser. Et si c'était simple de l'utiliser ?
En vidant mon /grenier, je suis tombé sur ce surprenant mais non moins intéressant article :
Web browser explained to command line users
Hi, dear command line user ! I know it's always been a difficult task to try and use something else than your favorit terminal, but today we gonna discover a new exciting tool commonly called a web browser.
Since you could feel a little bit lost in front of this new kind of interface, I decided to wrote this simple guide.
I won't take any screenshot for this tutorial since I know that you'll read it from your terminal, at least the beginning !
First of all, you should… Wait, aren't you convinced to discover a web broswser ? Don't worry. You'll see that it's not so different from your so loved command line.
So, I was saying: First of all, you should notice that the main input is not on the bottom of the screen but on the top of it.
Let's try our first command. You need to know that the web browser does not understand the usual shell syntax and commands. Actually it's fundamentally different, and its main fundamental difference is that you don't need to know it !
Actually you still need to begin by typing a command. Here is an example :
Type it, be prepared to a shock and then press your return key. (The schedule is important.)
Did you see that ? The output is not a raw text ! I know, in your terminal after typing some insane sequence of characters you could have colors in it. 16. Ok, you've got a "modern terminal" so it's 256. But here you can use up to 16,777,216 colors and you can get big text, small text, etc.
Some of you that love curses should be excited to see that in a web browser each pixel can be individualy set and this way you can display pictures !
But you haven't seen the best. There are hyperlinks. An hyperlink is a part of the output that links to another command. You just have to click on that to execute the command !
For instance, you can click on "contact" in the top left-hand corner to execute
<http://blog.exppad.com/contact>.
You've got it ! This is why you will not need to know the address syntax. It's better to know it, of course, but not mandatory since you can just go and wander from link to link.
There are actually a lot of interesting features in a web browser. For instance, you can set bookmarks. This is like shell aliases, but with hyperlinks. They appear in the interface and you can click on it !
Another interesting thing is the embedded text editor. You can see it on the bottom of the first address you've visited. You don't need nano any more.
I could spend a lot more lines to explain you why web browser is the future but you may not spend you time to read it so I will end now. Give it a try !
Bon ok, si vous êtes là c'est que vous saviez certainement déjà utiliser un navigateur : sur ce point vous n'avez sans doute rien appris. Mais ce qu'il est intéressant de noter, c'est à quel point finalement le navigateur reprend des éléments de la ligne de commande.
Ces éléments sont bien intégrés, ont naturellement évolué. Je crois en la sélection naturelle et pense qu'il est nécessaire de s'en inspirer pour redonner un coup de jeune au terminal.
Il y a plusieurs points qui pourraient changer :
- Cohérence
- Esthétisme
- “Wanderersfriendlyness”
Cohérence
Un gros problème de la ligne de commande selon moi est qu'elle est trop différent de l'interface graphique dans ses conventions.
Citons quelques exemples simples :
- L'entrée de texte qui ne suit pas
- Le copier-coller qui ne se fait pas avec ctrl+C ctrl+V,
- Les signaux (^C, ^Z, ^D, etc)
- Le curseur carré qui est troublant quand on n'y est pas habitué.
Je sais, on peut configurer certaines choses. Je sais, les signaux c'est important. Je sais, quand on sait l'utiliser c'est bien. Oui mais voilà, quand on sait. Si les conventions étaient plus unifiées avec l'interface graphique, on saurait « naturellement » s'en servir.
Sinon c'est frustrant donc les débutant s'en vont, par manque de temps ou de motivation. D'une part je pense que les débutant ont le droit de pouvoir découvrir la force de la ligne de commande et d'autre part on peut très bien la faire évoluer sans perdre les power users.
Les signaux par exemple empêchent empêchent les programmes en console d'utilsier certains raccourcis. C'est quand même dommage de ne pas pouvoir utiliser l'habituel ctrl+S pour sauvegarder par exemple. C'est comme ça qu'on se retrouve avec des programmes comme emacs qui doivent se contorsionner pour éviter les conflits en ajoutant des C-X devant la moitié des raccourcis pour qu'ils puissent passer.
Ce devrait être au terminal d'éviter au maximum les conflits en faisant par exemple comme screen qui préfixe tous ses raccourcis par ctrl+A. Parce que les raccourcis du terminal on les utilise moins que les raccourcis des programmes eux-mêmes.
Les plus attentifs d'entre vous auront peut-être remarqué que je me contredis : je veux un terminal qui n'intercepte pas de raccourcis mais en même temps je veux avoir les raccorucis usuels comme ctrl+C, ctrl+V, ctrl+X, shift+flèche pour sélectionner, etc. Eh bien il suffit de couper ces raccourcis lorsque une commande tourne, on n'en a pas besoin en général (et pour les cas pathologiques on ajoutera une option).
Alors oui, dans certaines situations on n'a accès qu'à un terminal à l'ancienne. Mais ça n'est pas une raison pour profiter de l'interface graphique lorsque celle-ci est disponible ! Est-ce que vous brideriez votre débit chez vous sous prétexte que dans votre maison de campagne y a pas l'ADSL ? Non, ce serait ridicule.
Esthétisme
La ligne de commande, ça fait peur et c'est moche (si si, c'est moche – ça a du charme si vous voulez, mais c'est moche).
Le fait d'utiliser une police monospace se défend, pour l'ascii art, les tableaux and co. Mais les 256 couleurs par exemple ? Encore trop peu de terminaux supportent les 16M de couleurs alors que tous les écrans les gère depuis des lustres !
Je ne suis pas partisan de l'idée qui consisterait à permettre un rendu HTML/CSS de la sortie du terminal. Ça mènerait immanquablement à des effets kikoo affreux et ralentirait inutilement la sortie mais entre ça et les 256 couleurs on a pas mal de marge de progression…
Alors je sais ce qu'on va me répondre :
Ce serait se tirer une balle dans le pied de vouloir utiliser les 16M de couleurs puisque le programme ne serait alors accessible qu'aux utilisateurs ayant un terminal moderne. Sauf qu'on a bien réussi à passer de 16 couleurs à 256. Donc rien n'est impossible et on pourraît bien imaginer une option pour activer les 16M de couleurs comme vim a une option pour activer les 256 couleurs.
Ça sert à rien, personne n'a besoin de plus de 256 couleurs pour vivre. Et en suivant ce raisonnement, on peut virer plein de choses de l'interface d'un ordi. On peut aimer le KISS, moi le premier, mais on peut aussi aimer avoir une belle interface. Et puis ça rejoint l'idée d'être cohérent avec m'interface graphique.
Et le nombre de couleurs n'est pas le seul point que l'on peut changer. C'est déjà tellement le bazar dans les termcap et terminfo que je vois pas ce qui nous empêche d'ajouter des features potentielles comme la possibilité d'aller bidouiller les pixels des caractères ou je-ne-sais-quoi.
Wanderersfriendlyness
J'ai gardé pour la fin ce qui me tient le plus à cœur. Derrière cet affreux mot (plus ou moins inventé pour l'occasion) se cache le principal défaut de l'interface en ligne de commande : on ne peut aller nulle part sans connaître à l'avance les destinations possibles. C'est la grande différence avec l'interface graphique dans laquelle on va de menu en menu en voyant à chaque fois toutes les possibilités qui s'offrent à nous. C'est aussi la faiblesse de l'interface graphique, bien sûr, puisque pour éviter de proposer trop de choses à la fois, il faut toujours un grand nombre d'étapes pour aller là où on veut alors que la ligne de commande permet ça en un seul coup.
Mais pourquoi opposer les deux ?
On peut tout à fait satisfaire power users et wander users en gardant pour les premiers toutes les possibilités actuelles de la ligne de commande tout en ajoutant pour les autres des infos du style : « Si vous voulez faire ce genre de chose, essayez telle commande. »
Et c'est là que les hyperliens interviennent ! Le texte ci-dessus montre bien leur intérêt et c'est effectivement eux qui ont fait le succès du Web. Il n'est pas nécessaire de connaître toutes les adresses web puisqu'en en connaissant quelques unes on peu en visiter beaucoup plus de proche en proche. Il serait tout à fait adapté de reprendre ce schéma pour les commandes : on retient les commandes que l'on utilise le plus puis pour les autres on y va de proche en proche.
Et pour cela, mettre en place des hyperliens entre commandes serait à la fois simple et efficace. Une séquence d'échappement particulière (y en a déjà tout plein, on n'est plus à ça près) pour définir un lien et c'est plié.
Imaginez que la recherche du gestionnaire de paquet vous permette de cliquer sur les noms de paquet qu'il retourne plutôt que de vous obliger à les recopier. Pour ceux qui n'ont pas de souris, il suffira de déplacer le curseur dessus puis de faire Entrer, c'est loin d'être techniquement complèxe. Vous vouliez ajouter des arguments pour configurer l'installation du paquet ? Faite Ctrl+Entrer pour éditer la commande et le tour est joué !
Prenons un autre exemple : vous voulez ajouter des fichiers au prochain commit du dépôt git courant ? Faite git status puis cliquez sur les fichiers qui vous intéressent ! On peut même imaginer que le lien est vers (git add [trucmuche]; git status) pour que l'affichage soit actualisé en live.
On peut imaginer énormément de situations où ça serait un gain de temps non négligeable : pour donner des arguments à un cp, mv, rm ou autre ; pour ouvrir un fichier à la ligne d'une erreur donnée par gcc ; pour faire facilement des interfaces curses cliquables, etc.
Des liens d'installation dans une recherche du gestionnaire de paquets
Franchement, si entre tous les trucs que je raconte dans cet article seuls les hyperliens étaient mis en place, je serais déjà hypercontent (sans mauvais jeu de mot).
Mais on peut envisager d'aller plus loins. Après les liens, l'article parle des favoris. Ça c'est pas compliqué, mais mettre les alias dans une petite liste sur le côté ça pourraît vriment améliorer l'expérience utilisateur.
Vous êtes en train de manger une tartine et ne pouvez donc taper au clavier que d'une main ? Pas de problème, il suffit de cliquer sur vos commandes favorites.
Puis à la fin une allusion aux formulaires est faite avec l'idée d'éditeur de texte intégré. C'est vrai d'une part que l'éditeur de texte est ce qu'on utilise le plus couplé avec le terminal alors il peut être intéressant d'imaginer une fusion des deux. Ça peut par exemple permettre d'avoir un éditeur de texte graphique (puisque géré par l'application graphique qu'est l'émulateur de terminal) mais qui fonctionne nativement par ssh ou autre.
Mais même sans aller jusque là, on peut par exemple envisager des widgets comme les cases à cocher. On trouve déjà ça dans emacs graphique pour le choix du thème de coloration par exemple. On peut aussi ajouter des champs de texte et j'imagine bien partant de là des programmes qui, appelés sans arguments, afficheraient une sorte de page de man listant tous les arguments avec une case à cocher à côté et si besoin un champ de texte pour donner un argument.
Vous ne vous rappelez plus des options de netstat ? Pas grave !
Conclusion
Tout ça pour dire donc que je pense que le terminal doit, mais surtout peut changer. La difficulté étant de faire vivre ces changements. Pour commencer les liens et widgets peuvent en fait s'émuler dans un terminal déjà existant, en faisant un screen-like.
On peut dans un second temps envisager de développer un terminal plus moderne. Il y a des tentatives comme finalterm mais il est encore loin d'être utilisable et ne va à mon avis pas assez loin. Ceci dit c'est déjà une très belle initiative dans ce sens.
L'état actuel de Finalterm, un projet prometteur
Mais ce qu'il faut surtout ce n'est pas seulement avoir un terminal qui gère tout ça : il faut des applications l'utilisant. C'est encore le problème des 16M de couleurs et on manque pour les terminaux d'un organisme fort comme le W3C l'est pour les navigateurs web afin de l'imposer convenablement.
L'idée serait alors d'imaginer des wrappers d'un programme vers une version utilisant ces standards, ce qui serait rendu possible par les liens notamment. Ces wrappers pourraient alors être développés complètement indépendemment du programme lui-même et ne devraient pas être trop durs à réaliser.
Bref, voilà donc quelques idées, même si j'en ai encore d'autres (scrolling horizontal possible, less appliqué à des sorties passées, fusion shell-terminal, etc) mais là j'ai déjà assez écrit comme ça !
Et surtout n'hésitez pas à donner votre avis sur ce que je dis, surtout pour me faire remarquer des trucs importants auxquels je n'ai pas pensé.
Autres lectures :
- https://github.com/jonas/tig/issues/227
- [à compléter]