Non, ce n'est pas du tout en arrière.
La "direction" a beaucoup à voir avec notre perspective. Un utilisateur satisfait du chemin actuel menant à des interfaces simples, "one experience all devices", verra l'interface de ligne de commande comme une régression ou une régression. Cela ne correspond pas à leurs attentes générales.
Un programmeur, un administrateur ou un utilisateur expérimenté peut très bien y voir une progression logique des outils en fonction de leur expérience. Beaucoup d'entre eux commencent par utiliser des outils d'interface graphique. Lorsqu'ils souhaitent ou doivent évoluer, ils comprennent rapidement pourquoi la CLI existe et cette progression résonne chez ceux qui construisent davantage d'outils de la CLI.
Paul Ferris l’a mentionné: http://www.linuxplanet.com/linuxplanet/opinions/1505/1
Pour moi personnellement, l'idée de syntaxe différencie les deux. Lorsque la syntaxe est quelque peu présente dans une interface graphique, le résultat n'est presque jamais bon et aussi souple que la syntaxe de la CLI bien pensée. Lorsque cela est associé aux canaux et à la redirection, l’interface graphique tombe à plat car elle n’est pas très utile en dehors des cas d’utilisation prévus.
Ma préférence personnelle à cet égard concerne les outils CLI qui offrent une option --gui ou --verbose suffisante pour permettre à un wrapper d’interface graphique d’interagir de manière robuste, y compris des barres d’état et d’autres éléments de base sur lesquels les utilisateurs se tournent vers l’interface graphique.
Bien sûr, le coût de cette opération est essentiellement constitué de deux programmes dont l’un est plutôt inutile sans l’autre, mais le principal avantage est d’incorporer un ou plusieurs grands outils de la CLI dans une interface graphique personnalisée sans modification desdits outils de la CLI. Le plus souvent, ceci est uniquement fait pour offrir une option d'interface graphique sur une CLI particulière, mais l'idée de piloter plusieurs outils avec une interface graphique orientée "processus" ou "cas d'utilisation" peut produire des résultats similaires à ceux de piping, redirection et script pour ce cas d'utilisation. en le rendant disponible aux personnes qui ne réaliseraient pas ces opérations assez régulièrement pour atteindre la maîtrise sans pour autant empêcher les utilisateurs de l'interface de ligne de commande.
J'ai rencontré cette approche sur SGI IRIX et ça m'a vraiment plu. Je me suis retrouvé à utiliser l'interface graphique ou la ligne de commande selon les besoins, et la bonne chose à faire était de savoir exactement ce que faisaient les boutons fantaisie.
Là où il y a beaucoup d'environnements d'exploitation différents, les interfaces graphiques peuvent différer considérablement sans que l'outil CLI soit affecté.
Je le vois aujourd'hui sous Linux avec des outils tels que les outils de disque / système de fichiers, où l'interface graphique peut ajouter beaucoup de valeur même aux utilisateurs familiers de la CLI.
Dans le cas de systèmes de fichiers / disques / périphériques connus, désactiver l'interface de ligne de commande n'est pas compliqué et il peut être scripté, bien sûr. Les erreurs peuvent cependant être douloureuses.
Là où ceux-ci peuvent ne pas être connus, ou peut-être que l'exécution des opérations n'est pas assez régulière pour rester solide et sans erreur, l'exécution de l'interface graphique fournit un environnement facilement vérifiable, des opérations chaînées et exécutées en toute confiance, aucun script requis.