Quand apprendre la version en ligne de commande d'un outil de programmation? [fermé]

Presque tous les outils de programmation ont une version en ligne de commande; beaucoup d'entre eux ont également une version gui. Il faut beaucoup de temps et d'efforts de mémorisation pour apprendre les différentes commandes et les différentes options / commutateurs de la version en ligne de commande.

J'ai donc quelques questions (qui ne sont pas nécessairement mutuellement exclusives):

1) Quand prendriez-vous la peine d'apprendre / de mémoriser les commandes dans la version en ligne de commande d'un outil qui existe également en version GUI?

2) De quels outils dois-je apprendre la version en ligne de commande? .... compilateurs? système de contrôle de version? etc

Je peux voir deux raisons pour lesquelles vous devriez apprendre les options de ligne de commande d'un programme:

1. Lorsque vous devez automatiser le programme d'une manière ou d'une autre - créer des scripts, un traitement par lots, etc.

2. Lorsque vous devez optimiser le comportement du programme - réduire l'empreinte mémoire, etc.

Quant aux outils que vous devez apprendre - eh bien cela dépend totalement de ce que vous voulez faire ensuite.

Beaucoup de bonnes réponses déjà. J'ajoute un point de vue supplémentaire.

Vous remplacez l'interface utilisateur graphique par des outils de ligne de commande, lorsque vous voulez sortir l'humain de l'équation / du processus. Quelques raisons et / ou avantages pour cela:

• Vous vous débarrassez de l'erreur humaine (en répétant la commande)
• Excellent pour tout type d'automatisation, par exemple le déploiement, la construction ou l'exécution de tests avec des entrées aléatoires.
• Vous obtenez d'être vraiment une puissance utilisateur. Il vous donne la possibilité de grimper sur l'échelle de la méta-programmation. Vous n'avez pas à effectuer vous-même chaque action (cliquez sur l'interface graphique), vous pouvez facilement l'écrire!
• Vous pouvez enchaîner les outils (pensez aux tuyaux Unix).
• Faites travailler les ordinateurs - vous ne faites pas évoluer, les ordinateurs font!

Quand le faire? Lorsque vous vous répétez.

Bien sûr, il y a de la place et du temps pour l'interface graphique. Mais si vous voulez vraiment exploiter la puissance des ordinateurs et surfer sur la vague de la loi de Moore, vous devez apprendre à écrire vos tâches.

Edit : Bonus supplémentaire. Vous pouvez porter ce T-shirt :)

Les mines sont:

1) Pour devenir plus productif . Pour moi, il est plus rapide de faire des choses dans un shell que de simplement cliquer. Je parle d'utiliser un outil, pas de configurer un service / outil / etc, car il est parfois plus rapide d'avoir un assistant et de simplement cliquer dessus Next Next Next, bien que ces assistants existent également dans les versions en ligne de commande :)

2) Pour utiliser la version en ligne de commande dans vos applications. Par exemple, supposons que vous souhaitiez convertir un PDF en fichier texte . Si vous utilisez la version GUI, ça va. Mais s'il fournit également une interface de ligne de commande où vous pouvez faire quelque chose comme:, ./pdf2text input.pdf output.txtalors si vous avez besoin de développer une application qui lit le texte d'un PDF, vous pouvez facilement l'utiliser, sans utiliser d'API, ou faire quelques ajustements .. .

3) Pour apprendre les choses générales d'une application. Par exemple, si vous avez installé diff sur Windows, et un frontal pour comparer deux fichiers. C'est parfait. Mais que faire si vous devez l'utiliser sur Linux ? Vous pouvez trouver le même front-end pour Linux, mais que faire s'il n'existe pas? Vous devrez réapprendre à l'utiliser sur Linux, installer un nouveau front-end et vous habituer à travailler avec. Si vous avez appris à utiliser la version en ligne de commande, vous n'en auriez pas eu besoin;)

À propos de 3) ... certaines personnes ont beaucoup de mal à s'habituer à travailler avec Git sous Windows. Ils disent qu'il n'y a pas de bons frontaux sur Windows, mais si vous apprenez simplement en ligne de commande, vous n'aurez pas de problèmes. Cela fonctionne de la même manière. Bien sûr, le problème est que parfois les gens ont peur de la ligne de commande ;)

Je vous suggère d'apprendre des versions en ligne de commande de:

• Des compilateurs comme gcc
• Débogueurs comme gdb
• Git ;)
• et de nombreux outils sous GNU / Linux que vous pouvez utiliser sous Windows comme egrep , awk , find , ...

Pourquoi avez-vous besoin de valider la syntaxe des paramètres en mémoire? C'est pourquoi manexiste et --help( /?si vous êtes en terre winblowz).

Je trouve que je peux rechercher les options pour à peu près n'importe quoi en moins d'une minute. L'objectif est de se rappeler ce que les commandes font , vous savez ce qu'il faut lever les yeux!

De façon pragmatique, cela revient à savoir s'il manque ou non une fonctionnalité à l'outil graphique, ou s'il est plus rapide à partir de la ligne de commande.

L'avantage secondaire de l'utilisation d'une ligne de commande, cependant, est que vous serez plus susceptible de lire la documentation et de comprendre ce qui se passe réellement. Surtout avec votre exemple de contrôle de version, le faire à partir de la ligne de commande vous en apprendra beaucoup.

• Compilateur: sera nécessaire pour les builds automatisés
• Make ou votre système de build: les builds automatisés détectent des erreurs
• Contrôle de version: Je pense que oui, mais c'est le moins important des trois. Mais alors je peux faire d'autres opérations en ligne de commande, par exemple grep à travers les messages de changement.

Mais vous n'avez pas besoin de mémoriser les options du compilateur ou de make; une fois ceux-ci configurés pour le projet, vous n'avez pas à les changer fréquemment.

Je pense que les avantages de l'apprentissage d'un outil en ligne de commande dépassent de loin les avantages de l'utilisation de l'interface graphique. Il y a de nombreuses fois que l'interface graphique perd des fonctionnalités, cependant, il ne serait pas juste de dire que c'est toujours le cas (par exemple, regardez cmake sous Windows - il n'y a aucune raison d'utiliser la ligne de commande en dehors des circonstances normales).

En ce qui concerne la mémorisation, il n'est pas particulièrement nécessaire de se rappeler que la commande de ce programme est définie la première fois que vous l'utilisez. Ajoutez simplement le manuel aux signets (si vous utilisez le manuel en ligne, sinon utilisez "man" sur * nix) et si vous avez besoin d'une fonctionnalité particulière (que vous n'avez pas mémorisée), référez-vous simplement au manuel. La mémorisation de ces choses devrait venir naturellement à l'usage. Par exemple, je lance très souvent "tar" et "gzip" à partir de la ligne de commande, mais je dois faire référence au manuel pour accomplir des tâches que je ne fais pas normalement.

Surtout, si vous expédiez un produit ou envoyez une sorte de code source ou autre à un collègue développeur, il est beaucoup plus facile d'inclure un squelette de commandes que d'écrire des instructions détaillées sur l'utilisation de l'interface graphique. Si le développeur ne comprend pas les options de ligne de commande que vous avez utilisées, il peut simplement les rechercher. Expliquer une interface graphique à quelqu'un n'est pas toujours la solution la plus portable.

Cordialement,
Dennis M.

Tout, pour que vous ne soyez pas dépendant de X11 / Windows pour le développement. C'est agréable de pouvoir se développer complètement à partir d'un terminal.

Réponse courte: Le meilleur moment pour changer (c'est-à-dire utiliser la ligne de commande) est MAINTENANT . Les vrais hommes utilisent le clavier. Les vrais hommes NE cliquent PAS. Période.

Réponse plus longue: dans une perspective à long terme, en plus d'être plus productif et donc plus précieux (moins susceptible d'être licencié), l'utilisation de la ligne de commande peut / va / devrait vous rendre plus intelligent (en raison d'une pratique / mémorisation substantielle) et plus sain (parce que utiliser les deux mains simultanément dans l'interface de ligne de commande au lieu d'une avec la souris est plus adapté à l'ergonomie).

Voici un article / essai fortement recommandé, " Pourquoi Windows provoque la stupidité ", à http://www.over-yonder.net/~fullermd/rants/winstupid/1

Je ne suis pas sûr que vous devriez jamais essayer de mémoriser les commutateurs sur un outil en ligne de commande. Si vous créez un script shell ou quoi que ce soit pour automatiser une tâche, vous feriez mieux de regarder tout cela - passez les trente secondes maintenant, pour éviter des heures de douleur à comprendre ce qui s'est mal passé plus tard. Si vous utilisez le même outil de ligne de commande encore et encore, vous devriez peut-être créer un script shell ...