Forum Astuces.divers Tutoriel sur la ligne de commande

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
5
17
mar.
2014

Bonjour,

je viens d'écrire un tutoriel, destiné au débutants, sur la ligne de commande, pour montrer qu'elle n'a rien de magique, et montrer aussi qu'on peut l'utiliser pour résoudre des tâches typiques qui sont réalisées normalement avec des outils graphiques. J'avais pensé en faire peut-être une dépêche dans l'espace de rédaction, mais me suis ravisé, parce que j'ai pas l'impression que ça puisse faire un dépêche sur ce site (c'est trop simple).

En fait, je ne suis pas totalement sûr du public qui peut être visé avec ce tutoriel : n'importe qui connaissant déjà la ligne de commande n'apprendra rien, mais j'ai peur quelqu'un de totalement débutant (donc le public visé) n'aura probablement pas le courage de le lire, ou du moins c'est mon impression, donc je suis finalement assez dubitatif à son sujet.

Bref, quoiqu'il en soit, je poste ici au cas où quelqu'un y trouverait un intérêt, ou voudrait tester le tuto sur une de ses connaissances allergiques à la console :) Une version html pour la lecture, et le fichier source markdown.

Édit : merci à tous pour les remarques qui font que ce tutoriel est maintenant beaucoup moins mauvais qu'avant !

  • # Images

    Posté par  (site web personnel) . Évalué à 4.

    Je pense qu'il manque des captures écrans, d'un terminal.

    Au moins pour que les lecteurs débutant n'écrivent pas le $ initial.

    Ensuite, plus loin, tu parles du PID, mais tu n'expliques pas comment l'obtenir.

    Bonne continuation.
    G

    Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

    • [^] # Re: Images

      Posté par  (site web personnel) . Évalué à 1.

      Merci pour le retour !

      Je pense que c'est une très bonne idée, les images, je vais voir ce que je peux faire.

      Pour le PID j'expliquais que c'était donné par top, mais c'est vrai que sans images ou exemples c'est pas forcément évident, donc on en revient au même problème.

      • [^] # Re: Images

        Posté par  (site web personnel) . Évalué à 1.

        C'est fait, il y a quelques images maintenant, et utilisateur toto créé pour l'occasion ;)

      • [^] # Re: Images

        Posté par  (site web personnel) . Évalué à 1.

        éventuellement montrer comment installer des paquets avec :
        sudo su -
        apt-get install aptitude
        aptitude install htop

        et recommander de ne plus utiliser apt-get, seulement aptitude pour gérer les paquets.

        htop est tellement plus agréable que top… sincèrement, autant montrer cet exercice de passage en root puis de gestion de paquet.

        Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

        • [^] # Re: Images

          Posté par  (site web personnel) . Évalué à 3. Dernière modification le 18 mars 2014 à 10:39.

          Le but du tutoriel est plutôt de fournir une introduction à la ligne de commande pour que, lorsque le néophyte voit un tutoriel qui lui dit de faire apt-get install ou aptitude il n'ait pas l'impression que c'est des commandes magiques, qu'il sache qu'une page man existe pour ces commandes, mais pas de donner des recettes de ce type en particulier, qui sont justement de toutes façons les commandes les plus typiques qu'il rencontrera dans n'importe quelle recette sur un forum de débutants. Ce qui m'inquiète aussi, c'est que installer des paquets est beaucoup plus spécifique à un moment donné et une distribution donnée (pour ce que j'en sais, peut-être qu'une autre distribution utilisant rpm ou que sais-je pour débutants fera un jour son apparition).

          Et entre apt-get et aptitude j'ai l'impression que ça change tous les jours lequel est recommandé, donc je ne me risquerai pas à dire ce genre de choses, surtout que le débutant va tout de suite être perplexe, se demander pourquoi il y a deux commandes alors, etc… j'ai peur que ça embrouille plus qu'autre chose.

          htop est tellement plus agréable que top…

          Comme je n'avais pas prévu de parler de système de paquets, je ne pouvais pas parler de htop, mais en y pensant je ne suis pas sûr que pour le débutant ça fasse une grande différence.

          En tous cas merci pour les remarques, je pense aussi que maintenant avec plusieurs images le tout est mois effrayant, et plus intuitif.

          • [^] # Re: Images

            Posté par  (site web personnel) . Évalué à 2.

            Il est préférable d'apprendre à se servir d'un gestionnaire de paquet : yum, rpm, apt-get, aptitude… plutôt que de voir comment télécharger les sources et les compiler comme il y en a sur beaucoup de tutoriels malheureusement.

            Tiens, comment un débutant pourrait connaître à coup sur le nom de la distrib qu'il utilise?

            A+

            Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html

            • [^] # Re: Images

              Posté par  (site web personnel) . Évalué à 1.

              Il est préférable d'apprendre à se servir d'un gestionnaire de paquet : yum, rpm, apt-get, aptitude… plutôt que de voir comment télécharger les sources et les compiler comme il y en a sur beaucoup de tutoriels malheureusement.

              J'ai rajouté un petit paragraphe expliquant qu'il convient d'utiliser le système de paquets de sa distribution, sans rentrer non plus dans les détails. Au pire, je pourrais renvoyer à un bon lien expliquant ces questions de paquets (faudrait juste en trouver un bien).

              Tiens, comment un débutant pourrait connaître à coup sur le nom de la distrib qu'il utilise?

              En regardant un fichier comme /etc/os-release ou peut-être uname -a, ou cat /proc/version. Je ne suis pas sûr qu'il y ait un standard la dessus. Mais bon, on peut espérer qu'il est au courant quand même de ça ;)

              • [^] # Re: Images

                Posté par  . Évalué à 2.

                Je ne suis pas sûr qu'il y ait un standard la dessus

                lsb_release ?

                • [^] # Re: Images

                  Posté par  . Évalué à 3.

                  Et même lsb_release -d ou lsb_release -a, sans argument, ça ne donne rien sur une Debian classique.

                  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                  • [^] # Re: Images

                    Posté par  . Évalué à 3.

                    Chez moi :

                    michel@debian:~ % lsb_release -d
Description:    Debian GNU/Linux testing (jessie)
michel@debian:~ % lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux testing (jessie)
Release:    testing
Codename:   jessie

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Images

                      Posté par  . Évalué à 3.

                      C'est ce que je dis, non ?

                      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

                      • [^] # Re: Images

                        Posté par  . Évalué à 3.

                        Désolé j'ai pas vu l'ironie :)

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Diverses remarques

    Posté par  . Évalué à 1. Dernière modification le 18 mars 2014 à 10:48.

    Parler de xdg-open pourrait être utile: on parle de débutants, qui ne savent pas nécessairement reconnaître le programme associé à fichier en voyant son extension. Sans compter que certains programmes ne sont pas très sympa à utiliser en ligne de commande.

    Quand tu parles d'arrêter/redémarrer la machine, tu peux aussi parler des hibernations ( tâches courantes ) via pm-[hibernate/suspend/whatever].

    Et dernier point abordable dans "En savoir plus sur le shell", les autres redirections, notamment ">" qui est quand même super utile ( ainsi que ">>" mais personnellement je m'en sers déjà moins personellement ).

    Sinon, en joujou utile, mais peut-être que ça va beaucoup trop loin la, c'est xclip, pour permettre de copier/coller le résultat d'une commande ou d'un fichier sans poncer la table.

    En tout cas, chapeau bas, c'est bien écrit, clair, et surtout portable ( donc, plus simple à utiliser, ça évite de dire "alors, ce passage la, pas pour nous parce qu'on est pas sous ) !
    Je pense le garder sous le coude pour le jour ou je dois expliquer à un dev windowsien comment on fait pour utiliser une machine qui n'a pas de serveur X :)

    PS: pour le fait qu'un non "débutant complet" n'apprenne rien, c'est raté: je ne me considère pas comme "débutant complet", et pourtant je ne connaissais pas nohup. Ni pkill. Enfin, ce n'est pas non plus vital, juste confortable :)

    PS2: dans la commande: "$ pkill firefox" pkill n'est pas coloré comme tu le fais avec les commandes habituellement. Idem pour cal, plus haut.

    PS3: le temps de lire, et tu as mis à jour, donc certaines remarquent peuvent être obsolètes :)

    • [^] # Re: Diverses remarques

      Posté par  (site web personnel) . Évalué à 2.

      D'abord, merci pour les remarques ! J'ai rajouté quelques uns des trucs que t'as dis (en fait tout à part xclip pour le moment).

      En tout cas, chapeau bas, c'est bien écrit, clair, et surtout portable

      Merci. En fait c'est vrai que j'ai essayé de faire portable, mais je m'aperçois aussi que c'est pas forcément évident ! Surtout que justement certains outils qui peuvent intéresser les débutants ne sont pas portables (apt-get, etc…).

      je ne connaissais pas nohup. Ni pkill.

      Ben moi je connaissais pas xdg-open ;) C'est installé par défaut sur les distributions grand public ? Comme j'ai une Gentoo et une machine virtuelle avec OpenBSD sur ma machine donc je suis pas hyper bien placé pour savoir ce genre de choses, donc ça complique un peu ma tâche ;)

      • [^] # Re: Diverses remarques

        Posté par  . Évalué à 2.

        C'est installé par défaut sur les distributions grand public ?

        Je pense que oui, mais j'ai beau utiliser une debian, je suis du genre à ne rien installé de base et ajouter juste les 10-20 outils que j'utilise réellement à la main donc…

        Le paquet qui contiens cet outil, c'est xdg-utils, donc je pense qu'il est utilisé par les gros DEs.

    • [^] # Re: Diverses remarques

      Posté par  (site web personnel) . Évalué à 1. Dernière modification le 18 mars 2014 à 11:47.

      dans la commande: "$ pkill firefox" pkill n'est pas coloré comme tu le fais avec les commandes habituellement. Idem pour cal, plus haut.

      Arf, pour pkill j'avais en effet fait une bêtise, mais après avoir mis cal en couleurs je me suis rappelé pourquoi je l'avais pas mis : ça me met aussi la sortie en couleurs ;) (limitations du markdown)

  • # Très long

    Posté par  . Évalué à 4.

    Je trouve ton howto très long avec beaucoup de texte et il rentre assez bien dans la description de la xkcd #1343 :
    XKCD #1343 sur l'utilité des manuels qui commencent par « comment lire ce manuel »

    Je pense que l'approche est orienté usage, ça c'est cool, mais il n'y a pas de sommaire (on ne sait donc pas rapidement ce qu'on va découvrir avec ton tuto). Les usages sont AMHA vraiment trop basiques, tu explique à des gens comment faire ce qu'ils savent déjà faire, pourquoi est-ce qu'ils liraient ? Ajoute des cas simples pas facile à faire autrement (supprimer tous les pdf ?).

    Les paragraphes débutant par « Note. » discutent de détails (techniques, historiques,…) qui ne sont pas nécessaires à la compréhension du tutoriel lors une première lecture.

    Alors pourquoi les mettre ? Met les en bas de la page ou qu'elle s'affiche uniquement si on clique sur une icône. C'est suffisamment long pour ne pas ajouter encore des détails.

    Remarque dactylographique. Notons qu'un des motifs qui peuvent rebuter un débutant dans la ligne de commande, est le simple fait qu'il faut écrire des commandes, et qu'écrire demande en soi une certaine compétence avec le clavier sous peine de se sentir mal à l'aise, lent, et d'avoir peur de faire des erreurs. C'est pour ça que sans doute un apprentissage de la dactylographie au clavier à l'aide par exemple d'un logiciel comme klavaro est une bonne idée, voire un prérequis pour une utilisation intensive des notions abordées dans ce tutoriel. C'est aussi un bon investissement en général pour quiconque ayant à écrire des textes substantiels de temps en temps (mail, rapport, etc…).

    Non, ça ne me semble pas pertinent d'en parler ou en tout cas pas là au début. Tu ajoute encore une barrière à la lecture. Si tu veux parler de ça, met-le à la fin AMHA.

    Pour le débutant, la ligne de commande apparaît parfois comme quelque chose de magique, les vieux sages disent que c'est puissant etc… donc c'est compliqué. En fait, pas du tout, vous faites des choses plus compliquées tous les jours (comme lire jusqu'ici).

    Non tu peut l'enlever ça sert à rien et ça catégorise ton lecteur, ce qu'il n'a pas forcément envie. Dire à son lecteur qu'il est un débutant, qu'il existe des vieux sage, ça donne pas particulièrement envie. Pourquoi parler de niveau. Tu peut commencer avec quelque chose de plus entraînant comme « on va découvrir ensemble comment se servir de … ».

    […] on se retrouve donc en ligne de commande : c'est-à dire une invite de commande […]

    Je suis pas certain que « invite de commande » soit plus compréhensible que « ligne de commande ».

    À mon avis finir l'introduction sur man et apropos n'est pas une bonne idée. Ça devrait être à la fin (« maintenant que vous avez suivi ce tuto, comment continuer à apprendre/progresser ? »). (Edit : en continuant ma lecture je vois que tu en parle plus en détail après, donc vraiment juste pas la peine d'en parler avant)

    Il suffit de fermer la fenêtre. Mais on peut aussi utiliser la commande exit sans arguments.

    Ou Ctrl+d (=EOF).

    Ton tuto est sympa, peut être sombre (moi ça me plaît, mais je ne suis pas sûr que ça plaise à tout le monde).

    La meilleure manière de convaincre tes lecteurs c'est de leur montrer le plus rapidement possible ce qu'il peuvent faire et pas de passer 5 minutes à dire que oui c'est compliqué mais promis on présente que des choses simples. Je pense qu'il faut que tu réduise ton intro et ton avant-intro pour que les gens aillent plus vite sur le contenu utile.

    Grosso modo je suis entrain de t'expliquer que ton tuto est bien, mais qu'il va prendre des TL;DR à tire-larigot.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Très long

      Posté par  (site web personnel) . Évalué à 1. Dernière modification le 18 mars 2014 à 15:11.

      Merci pour ces remarques !

      Comme j'étais globalement d'accord avec tout ce que t'as dis, j'ai modifié pas mal de choses en conséquence.

      Les usages sont AMHA vraiment trop basiques, tu explique à des gens comment faire ce qu'ils savent déjà faire, pourquoi est-ce qu'ils liraient ? (supprimer tous les pdf ?)

      J'ai rajouté un exemple pour copier des pdfs (mieux cp que rm, on sait jamais ;) ). D'un autre côté, l'objectif est justement de montrer comment faire des choses qu'ils savent déjà faire mais avec la console, et de montrer que celle-ci n'est pas magique, mais si je rajoute des explications sur les diverses expansions du shell ça risque de devenir magique.

      Alors pourquoi les mettre ? Met les en bas de la page ou qu'elle s'affiche uniquement si on clique sur une icône. C'est suffisamment long pour ne pas ajouter encore des détails.

      Je ne suis pas totalement sûr de quoi faire avec ça, mais vu que l'intro s'est sensiblement réduite, c'est plus aussi grave. En fait l'idée c'était d'avoir une méthode pour que lorsque j'explique quelque chose d'un peu plus compliqué, ou fais une remarque culturelle, celui qui se sente perdu puisse se dire : en fait c'est pas grave.

      Je suis pas certain que « invite de commande » soit plus compréhensible que « ligne de commande ».

      J'ai vu que « prompt » se traduisait par « invite de commande » en français, c'est pour ça que j'ai écrit ça. Mais c'est vrai que je ne suis pas sûr que ce soit très compréhensible, mais bon, avec les explications et images après ça devrait aller.

      Non, ça ne me semble pas pertinent d'en parler ou en tout cas pas là au début. Tu ajoute encore une barrière à la lecture. Si tu veux parler de ça, met-le à la fin AMHA

      C'est à la fin maintenant. En fait, je m'étais dis au début, que si je n'arrivais pas apprendre la ligne de commande à quelqu'un peut-être qu'au moins quelqu'un irait apprendre à se servir d'un clavier ;)

      À mon avis finir l'introduction sur man et apropos n'est pas une bonne idée.

      J'ai juste mis un lien maintenant disant que j'en parlerai plus loin.

      • [^] # Re: Très long

        Posté par  . Évalué à 2.

        Oui ça s'est bien amélioré.
        Pour les dates, je suis pas sûr que ce soit très utile (c'est utilisé par les gens qui n'utilisent vraiment pas d'environnement de bureau), mais c'est l'occasion de dire que -y c'est pour year et -m c'est pour monday (et ça devrait l'être pour toutes les options présentées).

        Les titres pourraient être plus court/plus fun (« la console : votre nouveau navigateur de fichier », « Quelques pistes supplémentaires d'approfondissement » → « et maintenant ? »,…).

        « Gérer les processus » je le mettrais en dernier de sa partie. La notion de processus n'est pas expliquée.

        On peut regretter que certaines tâches (comme gérer les périphériques tels les clés usbs), demandent encore un minimum de connaissance technique en ligne de commande (même si la commande pmount est déjà plus simple que mount). Mais rien ne dit que dans le futur ces quelques difficultés ne pourront pas être surmontées, permettant au moins technicien d'entre nous une utilisation de type desktop passant principalement par la ligne de commande si tel est son souhait.

        bashmount améliore un peu les choses

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Très long

          Posté par  (site web personnel) . Évalué à 1.

          Voilà, j'ai fais ces quelques corrections !

           Gérer les processus » je le mettrais en dernier de sa partie. La notion de processus n'est pas expliquée.

          Il était en dernier… jusqu'à ce que je me soit mis à rajouter des trucs en plus.

          bashmount améliore un peu les choses

          Ça a l'air pas mal. Mais pour pas en rajouter, j'ai plutôt rendu plus portable et maintenable ce paragraphe en enlevant toute mention à des problèmes spécifiques (ce qui fait donc du blabla inutile maintenant, mais c'est la conclusion donc c'est pas grave).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.