Pourquoi les consoles de terminaux sont-elles toujours utilisées?
Comme nous le savons tous, les consoles de terminaux viennent d'une époque où il n'y avait aucune chance d'interfaces graphiques, donc leur besoin est plus qu'évident.
Avec l'apparition d'interfaces graphiques, de nombreuses nouvelles applications étaient possibles, mais la plupart de ces programmes en texte uniquement sont passés à leur homologue graphique.
Cependant, les terminaux ont persisté, et pas seulement: il existe des services qui mentionnent généralement cela comme une fonctionnalité. L'exemple le plus courant est l'hébergement de services.
Bien sûr, cela signifie qu'au lieu de cliquer sur un bouton et modifier un fichier, un utilisateur doit mémoriser des centaines ou des milliers de commandes, puis faire quelque chose comme
Sudo nano /www/var/html/myfile.html
puis naviguer avec un curseur graphique pour modifier quelque chose, puis ctrl+X et Y et choisissez le fichier dans lequel enregistrer. En d'autres termes: l'anti-utilisabilité à son meilleur (le pire)
La même chose peut être vue pour de nombreuses autres commandes, ce qui précède n'était qu'un exemple. Un très simple: WordPress Installation en un clic vs installer WordPress à partir de la ligne de commande)
Donc ma question est: y a-t-il une raison logique pour laquelle les terminaux sont toujours utilisés (essentiellement, une raison technologique ou une raison de sécurité) ou est-ce juste une chose culturelle qui a persisté d'une certaine manière malgré tous ses problèmes?
EDIT: Ajout d'un autre cas: git. Je sais qu'il existe une interface graphique pour git, et ils sont beaucoup plus conviviaux que git sur le terminal. Alors ... pourquoi la version du terminal existe-t-elle?
Du point de vue UX, les consoles de terminaux présentent quelques avantages clés par rapport aux interfaces graphiques. Ces avantages sont rarement pertinents pour les utilisateurs finaux, c'est pourquoi les CLI sont utilisées presque exclusivement par les utilisateurs techniques et les "utilisateurs avancés" de nos jours.
Les opérations effectuées dans un terminal sont facilement reproductibles.
Imaginez avoir besoin de configurer 5 ordinateurs dans un but précis. Pour ce petit nombre, il n'est probablement pas utile de créer une solution automatisée pour les configurer tous. Vous n'aurez qu'à modifier les paramètres de chacun.
Sur un terminal, il est simple de copier et coller les commandes. Sur une interface graphique, vous pouvez vous familiariser avec l'emplacement de stockage des configurations, mais vous pouvez toujours vous contenter de cliquer. Les erreurs sont plus probables.
Cela concerne également la documentation et l'aide technique. Fournir quatre lignes pour copier et coller dans une console de terminal pourrait remplacer quelques paragraphes d'explication sur la façon de cliquer sur divers outils d'administration (d'autant plus que les instructions de l'interface graphique peuvent être parfaites uniquement pour l'une des interfaces, voir "Les interfaces GUI sont innombrables" ci-dessous) ).
Le suivi/audit est plus facile
Une interface de ligne de commande (CLI) conserve un enregistrement de ce que vous avez fait, que vous pouvez facilement extraire et conserver. Lorsque quelque chose ne va pas, votre patron demande: "Êtes-vous sûr que vous l'avez fait correctement?" vous pouvez avoir des preuves pour le prouver. Même si vous avez fait une erreur, vous pouvez plus facilement la voir et en tirer des leçons.
Scripter/automatiser est presque aussi simple que d'entrer des commandes
Tout le monde sait utiliser une souris pour ouvrir un fichier dans une interface graphique. Beaucoup moins de gens savent comment y parvenir automatiquement. Avec une CLI, l'automatisation de la tâche peut être presque aussi simple que de la taper à la main.
Les contraintes technologiques peuvent encore rendre la CLI convaincante
La connexion à distance à une boîte GUI nécessite une bonne quantité de bande passante, et la latence (retard dans la connexion) peut rendre l'expérience frustrante. Une connexion à distance CLI a une exigence de bande passante beaucoup plus faible, car elle ne fait que transmettre un petit texte d'avant en arrière. Et la latence est beaucoup plus facile à gérer lorsque vous tapez, que lorsque vous essayez de passer la souris sur une icône.
Une CLI peut être utilisée pour les entrées/sorties
Certains l'ont appelé The Age of the API , où les systèmes sont construits au-dessus des systèmes. Une CLI permet une interopérabilité similaire. Dans l'exemple de la question sur Git, il serait possible de connecter un autre "système d'entreprise" - tel qu'un système de suivi des défauts.
Par rapport à un SOAP ou même API Rest, les commandes CLI peuvent être faciles à développer et à tester.
Il n'y a que quelques obus standard; Les interfaces GUI sont innombrables
Si vous vous connectez à l'interface d'administration graphique de quelques services d'hébergement Web différents, vous verrez probablement qu'ils sont tous différents. Ce n'est pas difficile de fouiller et de comprendre où tout se trouve, mais cela prend du temps. L'année prochaine, l'hôte peut avoir mis à niveau sa solution, et maintenant tout est dans un endroit légèrement différent - encore une chose à apprendre.
Ce service d'hébergement utilise probablement toujours la même CLI. La nouvelle version est rétrocompatible avec l'ancienne. Les utilisateurs familiers avec Bash, PowerShell ou tout autre CLI sur le système peuvent éliminer le temps de montée en puissance passé à se familiariser (ou se familiariser à nouveau) avec cette interface graphique particulière.
En bref: les lignes de commande sont la langue ; le langage donne de l'expressivité.
Un exemple d'une interface texte que vous utilisez: Recherche Google . Imaginez si vous ne pouviez pas saisir vos requêtes sous forme de texte dans Google et que vous deviez sélectionner les documents que vous vouliez dans un menu de choix (comme l'ancien répertoire Web de Yahoo).
Jakob Nielsen, l'expert en ergonomie et chercheur en expérience utilisateur, a écrit avec Don Gentner un article intitulé "The Anti-Mac Interface" :
Gentner, D., et Nielsen, J .: L'interface Anti-Mac, Communications de l'ACM 39 , 8 (août 1996), 70–82
Dans ce document, les auteurs soulignent les lacunes de nombreux principes qui entrent dans les interfaces "GUI". Par exemple,
Voir et pointer
Le principe de voir et pointer stipule que les utilisateurs interagissent avec l'ordinateur en pointant les objets qu'ils peuvent voir à l'écran. C'est comme si nous avions jeté un million d'années d'évolution, perdu notre facilité avec un langage expressif et réduit à pointer des objets dans l'environnement immédiat. Les boutons de la souris et les touches de modification nous donnent un vocabulaire équivalent à quelques grognements différents. Nous avons perdu toute la puissance du langage, et ne pouvons plus parler d'objets qui ne sont pas immédiatement visibles (tous les fichiers datant de plus d'une semaine), objets qui n'existent pas encore (futurs messages de mon patron), ou objets inconnus (tous les guides de restaurants à Boston).
Ils continuent:
Si nous voulons commander de la nourriture dans un pays où nous ne connaissons pas du tout la langue, nous sommes obligés d'aller dans la cuisine et d'utiliser une interface à voir et à pointer. Avec un peu de compréhension de la langue, nous pouvons pointer sur les menus pour sélectionner notre dîner dans la salle à manger. Mais la langue nous permet de discuter exactement de ce que nous aimerions manger avec le serveur ou le chef.
Le article entier peut être intéressant à lire et contient de nombreuses réponses à votre question.
Ainsi, la langue (une ligne de commande) vous permet d'avoir une expérience plus riche. Mais comme vous le dites, cela ne signifie pas que la langue est mieux, comme l'illustre cet exemple qui (probablement par coïncidence) inverse parfaitement l'exemple ci-dessus:
Utiliser une interface de ligne de commande, c'est comme avoir à apprendre la langue coréenne complète juste pour commander de la nourriture dans la succursale de Séoul de McDonalds. Utiliser une interface basée sur un menu, c'est comme pouvoir pointer vers la nourriture que vous voulez et grogner et hocher la tête: elle transmet les mêmes informations sans courbe d'apprentissage.
- Joel Spolsky, Conception d'interface utilisateur pour les programmeurs, p. 76
Quel est le meilleur , une interface graphique ou une interface texte? L'interface texte nécessite plus de temps pour apprendre, en retour d'être plus expressive et puissante. Que cela en vaille la peine dépend de combien de temps vous comptez vivre dans cet environnement et de la richesse d'une expérience que vous aimeriez vivre.
Les interfaces graphiques des applications contemporaines sont généralement bien conçues pour faciliter l'apprentissage, mais il y a souvent un compromis entre la facilité d'apprentissage d'une part et la facilité d'utilisation, la puissance et la flexibilité d'autre part. Bien que vous puissiez imaginer une société où la langue était facile à apprendre parce que les gens communiquaient en pointant les mots et les icônes sur les grands menus qu'ils transportaient, les humains ont plutôt choisi d'investir de nombreuses années dans la maîtrise d'une langue riche et complexe.
Notez que l'apprentissage du "langage de ligne de commande" (un shell de type Bash dans un environnement de type Unix, ou peut-être l'équivalent de Windows) ouvre à l'apprenant à la fois un grand nombre d'expériences potentielles. Beaucoup ont choisi d'investir dans cet apprentissage, et pour ma part, je peux dire que cela a payé largement.
Enfin, pour répondre à votre question sur la raison pour laquelle les services (tels que les services d'hébergement) annoncent les interfaces de texte en tant que fonctionnalité: imaginez que vous êtes dans un pays étranger où très peu parlent anglais, aux prises avec des gestes et autres, et vous voyez un signe sur un établissement qui dit "On parle anglais ici". (De même, selon l'endroit où vous vivez, vous pourriez avoir vu des pancartes disant "Se habla español".) La publicité que vous mentionnez est similaire: pour ceux qui sont alphabétisés dans la "langue" de ligne de commande, cela équivaut à une invitation qu'ils peut s'attendre à avoir la riche expérience d'être expressif, sans se limiter aux interfaces graphiques qui ont déjà été conçues et mises en œuvre.
La version longue
La réponse est essentiellement incluse dans votre question elle-même:
un utilisateur doit mémoriser des centaines ou des milliers de commandes
Passer à des centaines ou des milliers de boutons ne serait pas une amélioration de la convivialité (et même si cela était beaucoup plus limité que la ligne de commande de texte).
Si vous avez essayé de créer une interface graphique suffisamment polyvalente pour couvrir toutes les tâches qui se font dans une fenêtre de terminal, votre interface graphique serait soit d'une complexité inhabituelle, soit d'une fonctionnalité inutilement limitée pour un sous-ensemble important de vos utilisateurs. Prenez vos exemples, par exemple: "l'installation en un clic" est géniale si vous ne voulez que les paramètres par défaut, mais elle est insuffisante pour autre chose. La modification d'un seul fichier dans un terminal peut sembler complexe, mais les utilisateurs de terminaux chaînent régulièrement plusieurs utilitaires de texte à des fins spécifiques; travailler sur la ligne de commande est généralement beaucoup plus similaire à l'écriture de programmes courts et à usage unique que de cliquer sur un bouton pour effectuer une tâche prédéfinie.
La plupart des tâches qui peuvent être améliorées en les déplaçant de la ligne de commande vers une interface graphique, l'ont déjà été - si vous ne voulez pas utiliser nano ( ou vi ou emacs ou autre), les éditeurs de texte à interface graphique ne manquent pas, par exemple. (Bien que si vous êtes déjà sur la ligne de commande et que vous ayez juste besoin de faire un changement rapide, c'est assez rapide pour simplement taper vi et effectuer cette modification rapide sans jamais toucher la souris.)
Mais personne ne va jamais écrire une interface graphique capable de, par exemple, trouver tous les fichiers dans un répertoire spécifique dont le nom correspond à un modèle donné, puis effectuer une recherche et un remplacement en leur sein, envelopper les originaux dans une archive tar et les pousser vers un autre serveur - parce que ce serait une tâche incroyablement trop spécifique pour une interface graphique à gérer. Mais lorsque vous avez besoin de faire quelque chose de spécifique comme ça, il est simple de regrouper quelques utilitaires UNIX pour le faire. Et pour capturer cela dans un script Shell afin que vous puissiez le faire à nouveau chaque semaine à partir de maintenant.
Les développeurs doivent tout le temps faire des choses incroyablement trop spécifiques . Le terminal est l'interface utilisateur la plus efficace et la plus facile à utiliser pour ce type de tâche.
La version courte
La ligne de commande échange découverte, en échange de efficacité et flexibilité.
L'utilisateur doit avoir appris les commandes à l'avance, il ne peut pas simplement fouiller dans les menus et les barres d'outils pour les trouver comme dans une interface graphique. Mais une fois appris, tous ces outils ne sont qu'à une poignée de touches et peuvent être combinés de nouvelles façons selon les besoins (alors que dans une interface graphique, chaque tâche doit avoir été pensée à l'avance par le concepteur.)
Suivi en réponse aux commentaires
Les fils de commentaires tout au long de cette question ont été supprimés à quelques reprises maintenant pour la conversation, mais comme les mêmes points semblent revenir, j'aimerais les aborder ici:
- Vous n'avez pas vraiment besoin de milliers de commandes, vingt ou trente suffiront.
Vrai! Sorte de. Le problème est que les 20 ou 30 commandes dont vous avez besoin ne seront pas nécessairement les mêmes que celles dont le prochain gars aura besoin - une interface graphique simplifiée contenant uniquement le sous-ensemble de commandes que vous utilisez régulièrement ne sera pas suffisante pour cet autre gars; et ne fonctionnera pas pour vous non plus, le premier jour vous devez faire quelque chose qui n'est pas routinier.
(Secondairement, une fois que vous avez pris en compte toutes les différentes options de ligne de commande sur chacune de ces commandes, ainsi que les façons dont elles peuvent être utilement regroupées, vous êtes vraiment à plus de 20 ou 30 interactions qui devraient être prises en charge dans votre interface graphique personnalisée ...)
Une interface graphique doit être conçue dans un but particulier. La ligne de commande en revanche est à usage général - elle peut être tout pour tout le monde, car si la fonctionnalité dont vous avez besoin n'est pas intégrée, vous pouvez l'ajouter vous-même.
- Cet exemple que vous avez donné d'une tâche incroyablement trop spécifique pour laquelle personne ne créerait une interface graphique pour: quelqu'un l'a fait.
Vrai! Je suis entré directement dans celui-là, yup. J'ai changé l'exemple pour le rendre un peu plus incroyablement sur-spécifique (mais non moins plausible).
Les wrappers GUI ont été créés pour de nombreuses tâches en ligne de commande, et sont certainement utiles (je passe beaucoup plus de temps dans la GUI github que d'utiliser git sur la ligne de commande, par exemple) - mais chacun d'eux n'est qu'un sous-ensemble de la de nombreux types de tâches pour lesquelles la ligne de commande est utilisée; mon point de vue était plus qu'aucune interface graphique raisonnable ne pouvait couvrir tout , ou même n'importe où près de le plus , tâches en ligne de commande. (Ou, diable, même ceux pour juste git lui-même; j'ai souvent besoin de revenir à la ligne de commande pour des choses que l'interface graphique ne peut pas gérer.)
- Découvrabilité ("La ligne de commande est plus détectable que vous ne le pensez"/"Les interfaces graphiques ne sont pas aussi détectables que vous le pensez")
J'utilise ici le terme "découvrable" dans son sens strict: un nouvel utilisateur peut comprendre comment utiliser un programme en utilisant simplement le programme. c'est-à-dire que si vous vous y attardez assez longtemps, vous pourrez comprendre comment cela fonctionne sans recourir à des ressources externes. (Je suis définitivement pas en disant que c'est la seule ou la meilleure façon pour un utilisateur d'apprendre à utiliser quelque chose; juste que c'est un avantage potentiel que les interfaces graphiques ont via la CLI.)
Je concède avec plaisir que les interfaces GUI mal conçues ne facilitent pas nécessairement la découverte.
Je ne suis pas d'accord avec les nombreux commentaires (certains supprimés, certains encore actuels) suggérant que la ligne de commande facilite la découverte, à un degré réel. Si vous devez lire la page man pour comprendre comment utiliser une fonctionnalité, ce n'est pas la possibilité de découverte; c'est apprendre. C'est super, mais c'est autre chose. Je ne pense pas qu'il y ait suffisamment de cohérence dans les options de ligne de commande pour divers outils pour faire valoir que l'apprentissage d'un outil vous aide à comprendre les autres; et il n'y a aucun moyen raisonnable pour un utilisateur CLI de découvrir l'existence d'outils qu'il ne connaît même pas encore (non, ls /usr/bin ne suffit pas; c'est plus analogue à "donnez-moi l'index du manuel, par ordre alphabétique".) Il existe des aides et des raccourcis, tels que la tabulation, mais ils sont plus utiles comme rappel après avoir appris quelque chose qu'ils ne le sont une façon de l'apprendre en premier lieu.
Donc ma question est: y a-t-il une raison logique
Les gens peuvent taper plus rapidement qu'avec une souris.
Une anecdote:
Dans une vie antérieure, je faisais partie d'une petite équipe travaillant sur un logiciel pour un marché de niche. C'était dans les années 90 lorsque le logiciel dominant sur le marché était un outil en ligne de commande. Cette démographie n'était pas nécessairement technophile, nous avons donc créé un logiciel beaucoup plus facile à apprendre étant donné qu'il avait une interface graphique.
Il a connu un succès modeste mais, au final, nous n'avons jamais réussi à détruire le leader de l'industrie. Une partie de cela pourrait être imputée au fait qu'ils étaient simplement l'option intégrée et qu'il est toujours difficile de bouleverser le titulaire. Mais une grande partie de notre incapacité à convaincre les clients des autres logiciels était que les personnes qui avaient travaillé sur l'outil de ligne de commande aimé il. Ils connaissaient les commandes, ils étaient rapides avec elle, et pouvaient tout faire rapidement en quelques touches.
Donc, même si c'était un outil plutôt lourd à apprendre, une fois appris, c'était un outil incroyablement puissant et rapide.
La leçon que j'ai apprise est que les interfaces graphiques ne sont ni meilleures ni pires que les terminaux/lignes de commande. Ils sont tout simplement différents. Parfois, l'un est meilleur que l'autre pour des tâches particulières, mais il est impossible de dire que l'un est simplement meilleur que l'autre. Tout dépend.
Je plaiderais pour deux raisons principales, dont aucune n'est universelle. Mais, les deux raisons sont de très bonnes raisons de préférer faire au moins certaines choses sur la ligne de commande:
- Programmabilité. Il est plus facile de coder par rapport à la norme IO que de manipuler une interface graphique par programme - ou d'écrire des intégrations personnalisées pour le macro runner pour chaque l'application que vous souhaitez automatiser ou intégrer.
- Efficacité. Lorsque vous souhaitez modifier
myfile.html, vous connaissez déjà le nom du fichier et l'éditeur que vous souhaitez utiliser. Assez souvent, il est juste plus rapide de taper ce que vous pensez que de traduire ce que vous pensez en une série de mouvements coordonnés de la souris dans un interface graphique hiérarchique - pour trouver votre éditeur et pour trouver votre fichier. (Il est à noter que la tendance dans les interfaces graphiques a été de fournir des mini-consoles, dans lesquelles vous pouvez simplement taper le nom du programme que vous souhaitez ...)
Dans votre exemple:
Sudo nano /www/var/html/myfile.html
Si je sais déjà que je dois modifier myfile.html en tant qu'administrateur, et si je connais bien mon interface utilisateur (la console et mon éditeur habituel), cela prend 2 à 3 secondes pour taper ceci:
Sudo nano /w <tab> v <tab> h <tab> m <tab> <enter>
Lorsque je suis déjà dans mon répertoire de travail, il me faut environ 1 seconde pour ouvrir un fichier dans vim si je connais le premier 1 ou 2 lettres du fichier que je recherche.
C'est encore plus rapide que lorsque j'ai une solution déjà chargée dans un IDE - même lorsque je connais le chemin complet et le nom de fichier. Dans une interface graphique, je dois scanner visuellement et naviguer dans une hiérarchie alphabétique pour trouver mon fichier. Pour moi, c'est probablement 5 à 15 secondes, en fonction de la taille de la hiérarchie des fichiers.
Cela ne ressemble pas beaucoup, mais cela ressemble à beaucoup. Et, si vous êtes dans et hors de centaines ou de milliers de fichiers et d'opérations sur ces fichiers par jour, les 4 à 14 secondes supplémentaires par fichier peuvent être notables. (Surtout si votre patron vous compare à votre homologue de l'assistant de ligne de commande ...)
Une interface de ligne de commande (CLI) n'est pas aussi hostile que la question le fait entendre. De même, nous pourrions soutenir qu'une interface pointer-cliquer est mauvaise car elle masque les composants internes et rend difficile la composition de commandes complexes.
Imaginons un petit enfant qui ne parle pas encore, mais qui pointe du doigt les choses. Oui, certaines tâches sont accomplies, comme demander du pain ou des boissons à table. Mais une fois que l'enfant apprend à parler, il revient rarement à pointer du doigt. Cela suggère que parler est plus puissant que pointer et grogner. Pourtant, à l'avenir, nous ne remplaçons pas tout par l'écriture de lettres.
Maintenant, de nombreuses interfaces utilisateur graphiques sont comme l'exemple enfant, pointer et cliquer. L'interface de ligne de commande est plus proche de parler à un logiciel, ou même de penser de manière plus appropriée à envoyer un SMS à un ami, ce qui est légèrement plus exigeant que de parler.
Dans un monde idéal, vous ne penseriez pas qu'une CLI est une horrible antithèse de l'UX, mais un complément de l'interface graphique. Il n'est pas nécessaire que ce soit/ou. Tout comme un adulte dans un pays étranger peut revenir au pointage. Vous devriez pouvoir choisir ce qui convient à la tâche.
Quelques idées fausses
Une ligne de commande vous oblige à apprendre des milliers de commandes.
Au contraire, il faut généralement en connaître au plus une douzaine pour être efficace. Tout comme dans une interface utilisateur graphique, vous devez toujours savoir ce que vous faites. Dans de nombreux endroits où vous avez installé de nombreuses applications, vous vous retrouvez avec le même problème. Vous ne pouvez tout simplement pas utiliser le programme XYZ à moins que vous ne connaissiez le nom du programme XYZ et que vous ne le trouviez dans l'interface graphique pour que vous le lanciez.
Connaître nano est un éditeur de texte est évidemment une chose mémorable, tout autant que de savoir que le bloc-notes est un éditeur.
Une ligne de commande est difficile à apprendre
Pas vraiment, c'est généralement très simple. Cependant, puisque seuls des utilisateurs quelque peu avancés l'utilisent, cela signifie qu'il est souvent adapté à eux. Cela ne signifie pas que le concept est difficile; juste qu'il n'est pas destiné à un usage occasionnel.
une ligne de commande est moins détectable que l'interface graphique
Parfois, les interfaces graphiques le sont, parfois non. Les interfaces de ligne de commande sont détectables, au moins les bonnes sont. De même, toutes les interfaces graphiques ne sont pas très utilisables. En fait, une très mauvaise interface de ligne de commande est meilleure qu'une mauvaise interface graphique. La ligne de commande est exploitable - vous pouvez facilement encapsuler la mauvaise ligne de commande en fonction de vos besoins. Une mauvaise interface graphique est une mauvaise interface graphique - il n'y a pas grand-chose à faire à ce sujet.
Une interface graphique est plus facile à utiliser
Parfois, lors de l'exécution de tâches simples qu'ils étaient censés accomplir, c'est vrai. Cependant, parfois, les gens s'enlisent dans des choses ridiculement simples qui sont triviales à faire, mais l'interface graphique ne vous permet pas de le faire. Sur une ligne de commande, ce n'est généralement pas un problème: prenez simplement une autre commande pour vous aider.
Une ligne de commande est-elle mauvaise UX?
Seulement si c'est mal conçu! Les lignes de commande et les commandes sont fournies dans différents packages, tout comme les interfaces graphiques. La plupart d'entre eux ne sont pas particulièrement élégants. Oui, la plupart des applications GUI sont également nulles. Certaines applications en ligne de commande ont une conception étonnamment bonne et donnent une bonne UX tandis que d'autres n'en ont pas.
Il n'y a rien de intrinsèquement mauvais dans une ligne de commande. En fait, j'ai rejeté les applications comme étant mauvaises car elles n'avaient pas d'interface de ligne de commande à proprement parler! J'ai également utilisé certaines applications pendant des années, même lorsque leur interface graphique est merdique, car elles et une bonne interface de ligne de commande. YMMV.
PS : C'est incroyable ce que vous pouvez faire avec une boucle. Ce que vous passeriez des jours à faire à la main peut être fait en quelques secondes. Si vous appréciez votre propre temps, vous utilisez la ligne de commande.
Eh bien, j'utilise des terminaux pour presque tout, mais pour quelques choses comme l'édition d'images. Je voudrais partager mes raisons de le faire, en mettant l'accent sur l'expérience utilisateur.
le Shell est un langage pour la composition des programmes
Les terminaux (et les coques) sont ce qui me permet d'avoir une conversation avec mon ordinateur. Je n'utilise pas le terminal pour faire des choses; Je l'utilise pour communiquer mon intention au système et le faire faire pour moi.
Par exemple, avec un Shell, je peux effectuer des tâches progressivement plus complexes. Tout ce que je peux faire à la main, je peux dire au système de le faire lui-même.
# report status of service
systemctl status mariadb
# do it on foo.com
ssh foo.com "systemctl status mariadb"
# do it for bar-1.foo.com through bar-8.foo.com
for i in {1..8}; do ssh bar-$i.foo.com "systemctl status mariadb"; done
Veuillez noter que ces trois commandes ne nécessitent à leur tour aucune nouvelle saisie si vous connaissez les raccourcis clavier de Shell pour la navigation dans l'historique et la modification de la ligne de commande, l'expansion de l'historique ou même la copie et le collage. Le résultat de chaque commande sera dans le terminal pour un examen et une comparaison faciles. Absolument tout peut être copié et collé n'importe où dans le système.
L'équivalent de la dernière commande avec une interface graphique nécessiterait que je me connecte à chaque système via un protocole de bureau à distance et vérifie manuellement l'état de chaque service en déplaçant une souris et en cliquant sur des icônes, en envoyant des coordonnées et des clics de souris et en recevant un flux vidéo contenant un fond d'écran et des fenêtres et des menus qui apparaissent. Il n'y aura pas de moyen simple de comparer les résultats côte à côte. J'aurais besoin du protocole pour gérer les presse-papiers partagés et copier les résultats dans un fichier sur mon ordinateur local, ou gérer autant de connexions lourdes et redimensionner les fenêtres pour masquer les fonds d'écran et d'autres choses.
Ok, maintenant je veux recevoir un e-mail si l'un d'eux tombe en panne.
while true; do
for i in {1..8}; do
echo "==> bar-$i.foo.com"
ssh bar-$i.foo.com "systemctl status mariadb"
done > /tmp/services.txt
if grep '^\s*Active:' /tmp/services.txt | grep -qv running; then
mail -s "service failed!" [email protected] < /tmp/services.txt
fi
sleep 10m
done &
Assez simple. Maintenant, parce que je n'ai aucune idée sur la façon d'extraire des informations d'une interface graphique rendue (OCR?), Je ne peux pas faire l'équivalent avec l'interface graphique.
Le problème que j'essaie de résoudre avec la méthode gui est que je n'ai aucun moyen de dire au système des choses comme for i in {1..8} ou if grep ... avec l'interface graphique, et c'est vraiment compliqué de lui dire "déplacez la souris sur cette coordonnée, double-cliquez et attendez ce temps estimé avant de cliquer dans cette nouvelle fenêtre ...", et c'est en supposant que je peux deviner où le une nouvelle fenêtre apparaîtra ...
Je peux faire des choses avec l'interface graphique, mais ce n'est pas une langue. Je ne peux pas lui dire ce que je veux faire donc ça peut le faire pour moi. Je dois le faire moi-même.
facile à communiquer
Comment donneriez-vous des instructions pour effectuer une tâche spécifique à d'autres personnes? Dans une interface graphique, vous devez leur dire de cliquer sur le renard, puis sur le hamburger (s'ils comprennent ce terme), menu, menu, menu, onglet, cliquer, quitter, cliquer, etc. Parfois, il est utile de publier des captures d'écran de le gui avec de grandes flèches rouges pointant vers où ils doivent aller.
Avec les commandes, il vous suffit de ... les écrire. Si les actions sont trop complexes et qu'ils vous font confiance, ils peuvent simplement copier et coller les commandes et en finir.
actions stockables
Cela peut être évident, mais vous pouvez combiner un ensemble complexe de commandes, les mettre dans un fichier et l'exécuter ... c'est de l'automatisation pure; comment un gui peut-il rivaliser avec ça?
Raccourcis clavier, globbing, extension d'accolade, expansion d'historique, etc.
Je pense que la plupart des gens qui se plaignent du Shell le font parce qu'ils finissent par taper de manière très répétitive (cela pourrait aussi être parce qu'il nécessite encore beaucoup plus de frappe, même si je dirais que c'est un avantage).
Le Shell possède de nombreuses fonctionnalités qui rendent son utilisation extrêmement efficace. Le hic, c'est que vous devez en apprendre davantage sur ces fonctionnalités. Tout est dans man bash et man zshall. C'est trop de même gratter la surface ici.
Eh bien, le fait est que le Shell offre de nombreuses fonctionnalités pour éliminer la répétition de votre travail. Les programmes spécifiques de Gui peuvent ressembler à des fonctionnalités d'historique et autres, mais le Shell fonctionne pour pratiquement tout.
terminal scrollback-buffer et historique Shell
J'ai configuré mon terminal pour enregistrer les 100 000 dernières lignes à afficher. Si je quitte mon ordinateur pendant un certain temps ou si je ne revisite pas un terminal dans un certain temps, je peux toujours revenir en arrière et voir ce que j'ai fait avec n'importe quel programme (terminal). J'ai obtenu ma configuration Shell Prompt pour afficher un horodatage avant et après l'exécution d'une commande. Je peux toujours dire combien de temps une commande s'est exécutée sans l'exécuter de manière préventive avec time. C'est si simple, mais comment feriez-vous cela avec un gui? Mettre en œuvre une sorte de lecture vidéo pour que le bureau enregistre toujours?
J'ai également le Shell pour enregistrer les dernières commandes 2000000 dans un fichier historique. Si je regarde le fichier, non seulement il a les commandes, mais chacun a un horodatage du moment où je l'ai exécuté. Il y a quelques mois, mon patron m'a demandé de faire une tâche que j'avais accomplie quelques mois après avoir été embauchée. Je ne me souviens pas maintenant mais je me souviens que je ne me souvenais pas alors Il s'agissait de plusieurs commandes complexes impliquant un ensemble de serveurs. Heureusement, je tenais toujours les commandes dans le fichier historique. C'était tellement incroyablement facile de simplement les trouver et de les réexécuter. J'étais tellement impressionné que j'ai augmenté ma limite de taille historique de deux ordres de grandeur. Que feriez-vous dans cette situation si tout ce que vous faisiez était avec un gui?
plus simple à programmer
Les programmeurs sont également des utilisateurs. La facilité d'écrire des programmes de terminal fait également partie de l'expérience utilisateur, et c'est certainement une raison pour laquelle tant de nouveaux programmes sont écrits pour fonctionner pour un terminal.
Vous n'avez pas à gérer la création de fenêtres et de widgets, et une boucle de rendu. Vous obtenez simplement vos arguments à partir d'un tableau et imprimez du texte sur la sortie standard.
La programmation d'un terminal au lieu d'une interface graphique a également une autre implication: les fichiers de configuration de texte destinés à être édités à la main. À quand remonte la dernière fois que vous avez utilisé un programme GUI et que vous deviez le configurer en ouvrant un fichier, en le modifiant puis en redémarrant un programme? Un utilisateur d'un programme GUI s'attend à pouvoir le configurer via GUI.
Pour le programmeur, cela signifie non seulement qu'il doit écrire et lire la configuration dans des fichiers, mais qu'il doit également implémenter des widgets pour cela.
Comme le programmeur s'attendra à ce que l'utilisateur utilise les widgets, la modification manuelle du fichier de configuration sera probablement une expérience sous-optimale. Pour l'utilisateur, cela présente également des inconvénients:
- il ne pourra pas facilement partager la configuration avec d'autres ordinateurs et amis.
- il ne pourra pas y ajouter de commentaires car ils seront écrasés.
- il peut être problématique de suivre les modifications du contrôle de version.
entrée et sortie unique
Lorsque je rencontre des problèmes avec un programme et que le message d'erreur n'est pas trop utile, je l'exécute avec strace. La sortie de strace et le programme sont combinés, et je peux alors voir ce qu'il a fait qui a causé l'erreur juste avant l'impression du message qui me concerne. Si le programme ne se termine pas après la première erreur, je peux également transmettre la sortie à sed '/message/q' ou similaire pour le faire tuer le programme lors de l'impression du message.
Si je débogue dans une interface graphique, l'erreur va probablement apparaître dans une fenêtre contextuelle et le message n'aura pas été transmis via un appel système. Je peux imprimer tout ce que le programme a fait avec strace, mais trouver l'erreur dans la sortie sans arrêt va demander plus de recherche que je ne le voudrais. Les programmes Gui ont également tendance à faire plus de choses pour faire le même travail, donc le coupable de l'erreur va probablement être caché parmi de nombreuses lignes de messages qui transmettent des appels système qui ne sont guère pertinents pour la tâche que j'avais besoin de faire.
En un mot: la dysiconie. C'est ma propre monnaie, par analogie avec la dyslexie, et cela signifie que j'ai vraiment du mal à essayer de comprendre ce que les petites images stupides dans une interface graphique typique sont censées signifier. Je sais qu'ils sont censés être intuitifs, mais pour moi, ils ne le sont pas. Je pense que cela pourrait être vrai pour plus de gens que vous soupçonnez, ou pourquoi les interfaces graphiques ajoutent-elles souvent du texte sous leurs icônes?
Bien sûr, avec une utilisation prolongée, je mémoriserais quelques icônes courantes (bien que je ne comprenne toujours pas pourquoi elles sont censées être `` intuitives ''), mais me confronter à une nouvelle et encore une fois, je ne sais rien. Pire, il n'y a pas de bon moyen de rechercher une photo **. Avec une commande que je ne connais pas, je peux simplement lancer "man étrange_commande", regarder dans l'index du manuel du programme ou utiliser une recherche Google.
Les humains sont des créatures naturellement verbales - après tout, le langage est ce qui est censé nous distinguer du reste des animaux, n'est-ce pas? Pour ceux d'entre nous qui utilisent des langues alphabétiques, un bon vocabulaire de lecture dans notre langue maternelle serait de plus de 50 000 mots. (Ceux qui ont plusieurs langues peuvent facilement ajouter 10K ou plus par langue, selon la maîtrise.) Nous pouvons soit rechercher des mots inconnus dans un dictionnaire, soit déduire leur signification du contexte. L'ajout des quelques milliers (pas des centaines de milliers) nécessaires pour utiliser une CLI à cette base est facile à faire.
Tout cela pour dire que pour la plupart des personnes alphabétisées *, l'utilisation d'un terminal/CLI n'est qu'une extension facile des compétences qu'ils possèdent déjà. Une fois que l'on s'y familiarise, elle est généralement supérieure aux méthodes graphiques pour toute tâche qui n'est pas intrinsèquement graphique (comme le dessin).
PS pour @nekomatic: Pour des preuves, que pensez-vous de cela: http://www.pewresearch.org/fact-tank/2015/10/19/slightly-fewer-americans-are-reading-print-books- new-survey-trouves / Littéralement, le premier lien a trouvé la recherche de "pour cent des Américains qui n'ont pas lu de livre cette année". D'après le lien "Environ 27% des adultes ont déclaré n'avoir lu aucun livre au cours de l'année écoulée ..." et "Le nombre médian de livres lus par des femmes était de cinq, contre une médiane de trois pour les hommes ..." Si ce n'est pas de l'analphabétisme fonctionnel, c'est quoi?
* Je soupçonne que la popularité des interfaces graphiques va de pair avec l'augmentation de l'analphabétisme fonctionnel. De même, entrée et sortie vocales.
** Même les langues idéographiques comme le japonais (et je pense que le chinois, même si je ne l'ai jamais étudié) ont des systèmes de recherche de kanji dans un dictionnaire.
Je suis peut-être sur le mauvais site, mais ...
L'expérience utilisateur n'est pas le seul programme de conduite forcée.
La création et la modification d'un programme sont beaucoup plus simples si vous ne vous occupez que des entrées et sorties des terminaux.
Les humains ne sont pas le principal utilisateur des programmes terminaux
Les commandes dans un terminal sont les mêmes que celles utilisées par la machine derrière la plupart des graphiques, c'est une très bonne chose pour tester des parties de choses compliquées. Presque chaque ligne parcourue par un terminal appelle plus d'un programme en les liant ensemble, le graphique que j'obtiens à partir d'une belle interface graphique peut faciliter l'apprentissage rapide de quelque chose, mais cela ne m'aide pas à dire à la machine quoi faire à ce sujet .
et parce que je suis ici: focus
Après avoir utilisé beaucoup de programmes, vous savez exactement où chercher les informations que vous souhaitez (si l'écrivain n'est pas un imbécile), qu'il s'agisse de texte n'est pas vraiment un obstacle une fois que vous avez gravi la courbe d'apprentissage et ne changez pas de focus pour effectuer le prochain changement en utilisant éventuellement un programme différent est un point positif.
Pour deux raisons simples
- Ça marche
- C'est puissant
Juste pour ajouter à ce qui avait été dit, car à la fin de la journée, une interface graphique n'est qu'un joli front-end pour un utilitaire de ligne de commande.
Chaque fois que vous cliquez sur un bouton, une commande est émise. Il y a des actions qui n'ont pas de bouton, mais il n'y aura jamais de bouton avec une action que vous ne pourrez pas effectuer sur le terminal.
Par exemple, dans Windows, vous pouvez cliquer avec le bouton droit sur n'importe laquelle de vos icônes d'accès direct sur votre bureau et vous pourrez y trouver la commande qui est exécutée une fois que vous double-cliquez dessus. Vous pouvez directement entrer cela dans une console de terminal et la même action sera exécutée.
Dans Windows, il est plus difficile d'apprécier la simplicité et la puissance de la ligne de commande car leur Shell manque de nombreuses fonctionnalités utiles présentes dans les shells Linux, comme la complétion de tabulation, par exemple.
Compatibilité descendante et systèmes embarqués
Ce système vieux de 30 ans qui fait fonctionner l'avionique dans un B-52 doit encore être maintenu. Tout comme le microcontrôleur de la pompe qui alimente le château d'eau ou le système qui fait fonctionner les tapis roulants de mon usine.
Reprise après sinistre
Il faut plus de temps au système pour faire tourner l'interface graphique à partir d'un démarrage à froid, temps que je n'ai peut-être pas. Si j'ai besoin de faire fonctionner une machine de sauvegarde en ce moment hors d'un périphérique de stockage externe dans une situation de vie ou de mort, je ne veux pas rester assis pendant 60 secondes supplémentaires.
Surveillance, diagnostics et gestion à distance
Cela s'applique en particulier lorsque vous êtes dans une situation de bande passante limitée. Si mes liaisons de communication à large bande primaire, secondaire et tertiaire ont échoué, mais j'ai toujours un modem 56k, je ne vais pas faire glisser ce circuit vers le bas en envoyant des données GUI dessus. Je vais utiliser une CLI pour me connecter à distance aux routeurs afin que je puisse comprendre ce qui ne va pas et les faire fonctionner à nouveau.
Je pense que le terminal est une meilleure solution pour les utilisateurs expérimentés. Il peut vous amener directement dans l'action, vous pouvez effectuer n'importe quel type de tâche avancée avec, et il est facile à développer.
Parfois, le terminal est inévitable. Certaines choses ne peuvent tout simplement pas être faites sur une interface graphique, vous devez donc le faire sur le terminal à la place.
Certaines personnes, comme moi, préfèrent le terminal aux interfaces graphiques pour certaines applications. Par exemple, je lance un bot et le terminal est mon environnement de développement idéal pour les applications codées (j'utilise également des outils GUI pour le coder, mais le terminal est toujours mon go-to pour l'exécuter).
Pour être bref (en quelque sorte), étant donné qu'un certain nombre de bonnes explications ont été fournies, il existe de nombreux systèmes essentiels où la mise en œuvre d'une interface graphique est tout simplement impossible. C'est généralement la situation avec n'importe quel serveur qui ne fera que quelques tâches et vous devez vous assurer qu'il dispose de toutes les ressources disponibles uniquement pour ces tâches. Si certaines de ces tâches impliquent de servir une application GUI, cela devrait être prévu pour cela, mais si tout ce qu'un serveur va faire est de servir des pages Web, vous ne voudrez que des programmes absolument nécessaires pour qu'il ne fasse rien d'autre que de servir ces pages.
Les programmes GUI auront toujours beaucoup plus de traitement et de stockage de données que la plupart des programmes de ligne de commande, sinon aucun, simplement en raison de la nature de la demande d'informations supplémentaires.
Git est un autre excellent exemple. Vous l'utiliserez principalement sur des serveurs situés à des centaines/milliers de kilomètres de distance pour lesquels vous ne pouvez interagir que via un terminal afin que des ressources minimales vous soient allouées pour communiquer avec le serveur. À ce stade, vous voudrez être très familier avec la ligne de commande afin de pouvoir travailler avec elle aussi confortablement qu'un programme GUI.
Contrôle et précision
L'utilisation du terminal nécessite la connaissance des commandes qui le font fonctionner. Ce n'est pas intuitif ni facile pour le débutant. Mais une fois que l'utilisateur connaît les commandes, une grande partie des fonctionnalités est plus rapide à taper qu'à trouver l'élément sur l'interface et interagir avec la souris.
Certaines fonctionnalités des interfaces graphiques peuvent se trouver derrière des seuils de sécurité qui protègent l'utilisateur contre lui-même. En utilisant les commandes de la console, l'utilisateur a un contrôle absolu sur ce qu'il fait.
Certaines réponses se sont rapprochées, mais aucune n'a atteint le but.
La principale raison des programmes terminaux. La toute première chose et la plus simple à présenter à un utilisateur est un visage textuel. Ce visage textuel est dans la langue de l'utilisateur. Il a besoin du minimum de puissance de calcul et d'interface pour permettre la communication par rapport à tout ce qui est nécessaire pour présenter une interface graphique. En plus de cela, une interface graphique nécessite beaucoup plus de mémoire et de ressources informatiques et de puissance juste pour arriver au point où serait un terminal. Une interface graphique nécessite également un matériel plus sophistiqué qui peut l'afficher. Des LED simples peuvent présenter toutes les informations textuelles nécessaires au fonctionnement des serveurs les plus puissants mais ne peuvent pas afficher plus que des graphiques très simples.
Ensuite, en ce qui concerne quelque chose à cliquer, la possibilité d'entrer des commandes en langage humain dépasse de loin la puissance que l'on peut utiliser en cochant des cases ou en cliquant sur des boutons. La portée et la précision que l'on peut transmettre en quelques mots simples sont d'une grande portée et sans restriction. Que faire si la couleur "chartreuse" n'est pas une des cases à cocher mais c'est une option dans le programme?