GameShell, apprendre les rudiments du shell en s'amusant

Posté par  . Édité par claudex et Pierre Jarillon. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
80
26
mar.
2021
Ligne de commande

Il y a 4 ans, j'ai pris en charge un nouveau cours intitulé « système d'exploitation » en première année de licence. Le programme est assez large, avec un peu d'architecture, un peu de système, et même un peu de réseau. Là dedans, je devais faire une introduction au shell. Le risque avec ce genre du truc, c'est de se retrouver avec un catalogue de commandes qui rebutera même les étudiants les plus motivés.

Et c'est comme ça qu'est né GameShell, ou gash pour les intimes. GameShell est un jeu où il faut entrer des commandes dans un shell (bash) pour valider des « missions ». Comme il n'y a pas eu de gros bug ces deux dernières années, je me dis que je pouvais en faire la pub. (Attention, il reste probablement plein de bugs. C'est juste que les étudiants ne sont pas encore tombés dessus !). Ça peut intéresser les gens qui veulent apprendre, ou enseigner les rudiments du shell.

Le code est disponible sur GitHub (promis, je changerais un de ces jours) avec une licence GPL : GameShell sur GitHub

N'hésitez pas à me faire des retours d'utilisation, des rapports de bugs, proposer des fonctionnalités, ajouter des missions, etc.
Si vous l'utilisez « en public », ça serait juste bien d'inclure un lien vers le dépôt et / ou mon nom.

GameShell est un jeu en ligne de commandes, où le joueur doit taper des commandes bash pour valider des « missions ».

Sommaire

GameShell

Pour simplifier, GameShell c'est juste (!?) une session bash avec un gros fichier .bashrc, et une variable $HOME ad-hoc. L'idée de départ est due à R. Lepigre, qui était alors en thèse et qui participait à ce cours.

On effectue des opérations standards sur les fichiers, les répertoires ou les processus dans un contexte plus ludique.

Au démarrage, voila ce qu'on a :

$ ./start.sh
============================ Initialisation de GameShell ============================
************************************************
*                                              *
*     Commencez par taper la commande          *
*       $ gash show                            *
*     pour découvrir le premier objectif       *
*     et                                       *
*       $ gash check                           *
*     pour valider vos missions.               *
*                                              *
*     La commande                              *
*       $ gash help                            *
*     affichera la liste des commandes gash.   *
*                                              *
************************************************
[mission 01] $

On se retrouve devant un prompt, et on peut commencer les missions. Toutes les commandes utilisées sont standard, sauf la commande gash.

[mission 01] $ gash show

     _________________________________________________________
()==(                                                        (@==()
     '________________________________________________________'|
       |                                                       |
       | Objectif                                              |
       | ========                                              |
       |                                                       |
       | aller tout en haut du donjon                          |
       |                                                       |
       |                                                       |
       | Commandes utilisées                                   |
       | ===================                                   |
       |                                                       |
       |   cd LIEU                                             |
       |     permet de se déplacer dans un lieu                |
       |                                                       |
       |   pwd                                                 |
       |     permet d'afficher le lieu actuel                  |
       |                                                       |
       |   ls                                                  |
       |     permet d'afficher la liste des lieux accessibles  |
       |     depuis la position actuelle                       |
       |                                                       |
       |                                                       |
       | Rappel                                                |
       | ======                                                |
       |                                                       |
       |   gash restart                                        |
       |     permet de redémarrer la mission à zéro            |
       |                                                       |
     __)_______________________________________________________|
()==(                                                         (@==()
     '--------------------------------------------------------'

[mission 01] $

Cette mission n'est pas trop difficile. Voila ce que fait un étudiant typique :

[mission 01] $ ls
Chateau  Echoppe  Foret  Montagne
[mission 01] $ cd Chateau
[mission 01] $ ls
Batiment_principal  Cave  Donjon  Entree  Observatoire
[mission 01] $ cd Donjon
[mission 01] $ ls
Premier_etage
[mission 01] $ cd Premier_etage
[mission 01] $ ls
Deuxieme_etage
[mission 01] $ cd Deuxieme_etage
[mission 01] $ ls
Haut_donjon
[mission 01] $ cd Haut_donjon
[mission 01] $ ls
[mission 01] $

Toute personne qui ne comprend pas la soluce de cette première mission devrait probablement faire une partie de GameShell !

Pour valider la mission en cours et passer à la suivante, il faut utiliser gash check

[mission 01] $ gash check

La mission 01 est validée

****************************************
*  Tapez la commande                   *
*    $ gash show                       *
*  pour découvrir l'objectif suivant.  *
****************************************
[mission 02] $

Bien sûr, si on n'est pas en haut du Donjon, la mission n'est pas validée, et il faut recommencer à partir du point de départ !

Je vous laisse découvrir la suite, mais les missions deviennent globalement de plus en plus complexes et permettent de se familiariser avec les commandes de bases, les motifs, les fichiers cachés, les redirections, les processus, etc. Tout ça, sous couvert de missions plus ou moins farfelues comme trouver des pièces d'or dans la cave, tuer des générateurs de chats, tricher à une épreuve de calcul mental, etc.

Il y aurait des tas de missions que je voudrais ajouter (quelques options de ls, recherche dans l'historique des commandes, liens symboliques, expressions régulières, etc.) mais comme mon TP ne fait que 3h, j'ai du m'arrêter à un moment !

Les retours des étudiants sont plutôt bons. Ils arrivent à faire des trucs assez compliqués et le problème principal est qu'ils ne parviennent pas toujours à réutiliser les commandes dans un contexte moins ludique.

Utilisation

Pour faire toutes les missions, il faut avoir :

  • un terminal avec bash
  • les paquets debian / ubuntu psmisc nano tree x11-apps

python3 (pour la génération des « parchemins » et la mission 33) et gcc (pour la mission 30) sont également nécessaires mais le joueur ne les utilise pas directement, et ils sont normalement installés par défaut.

avec l'archive

Après ça, il suffit de récupérer l'archive et l'extraire

$ wget https://github.com/phyver/GameShell/raw/master/GameShell.tgz -O -  |  tar -xz
$ ./GameShell/start.sh
...
...

Il est toujours possible de quitter GameShell (avec Control-d ou exit), et on pourra redémarrer à la mission en cours.

depuis le répertoire du dépot

Vous pouvez cloner le dépot et lancer GameShell directement

$ git clone https://github.com/phyver/GameShell
$ ./GameShell/start.sh
Vous êtes en train d'exécuter GameShell
dans l'arborescence de développement.
Faut-il le continuer ? [o/N] o
...

Il n'y a normalement pas de problème à lancer GameShell dans le répertoire de développement.

La suite

Si l'intérêt suscité par cette dépêche est suffisant, je ferai une deuxième partie avec un peu plus de détails techniques :

  • les commandes spécifiques GameShell
  • créer des nouvelles missions
  • architecture de GameShell
  • des trucs à faire, ou pas

Amusez vous bien !

Aller plus loin

  • # Trop fort !

    Posté par  . Évalué à 10.

    Bravo à vous deux pour ce beau projet. Il faut beaucoup de travail entre un prototype qui marchotte et une version utilisable par des élèves.

  • # Dans le même genre

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

    Terminus : un jeu d’aventure pour apprendre à utiliser la ligne de commande
    https://linuxfr.org/news/terminus-un-jeu-d-aventure-pour-apprendre-a-utiliser-la-ligne-de-commande

    • [^] # Re: Dans le même genre

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

      Très chouette aussi !
      L'avantage avec GameShell, c'est que ça se joue dans le "vrai" terminal.
      l'avantage de Terminus, c'est que c'est plus ludique…
      Merci pour le travail !

      • [^] # Re: Dans le même genre

        Posté par  . Évalué à 9.

        C'est exactement ça !
        Je crois que j'étais tombé Terminus à l'époque, mais ça ne m'avait pas vraiment convaincu. Je cherchais effectivement un truc qui se rapproche le plus possible d'une utilisation "normale" d'un shell.

        Avec le recul, je pense que c'était une bonne idée : même avec GameShell, de nombreux étudiants ont du mal à réutiliser les commandes. Ils ont compris qu'ils pouvaient faire cd Chateau/Donjon, mais me demandent "Comment on fait pour changer de répertoire ?" (J'exagère à peine !)

        Je pense que ça aurait été encore pire avec un jeu qui se joue dans un navigateur.

        GameShell est aussi beaucoup plus minimaliste : pour lancer une partie, il faut un shell, et un fichier de 40kio. (C'était l'idée originale de Rodolphe Lepigre : une session bash avec un .bashrc spécial pour enrober.)
        C'est un peu pervert de devoir utiliser Nodejs pour apprendre à utiliser un shell ! Non ?

        Sans avoir vraiment regardé les sources de Terminus depuis, je pense que GameShell est aussi plus modulaire. Pour ajouter une mission, il suffit d'ajouter quelques fichiers textes / scripts dans un répertoire.

        Bref, GameShell correspond beaucoup plus à ce que je cherchais ! :)

        • [^] # Re: Dans le même genre

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

          même avec GameShell, de nombreux étudiants ont du mal à réutiliser les commandes.

          Une fois la solution validée, redonner une explication basée sur la mission pourrait aider à mémoriser le fonctionnement de la commande. Par exemple, à la fin de la mission 1, en affichant l'arborescence complète (avec la sortie de tree) et des exemples de l'utilisation de cd sur cette arborescence.

  • # Si tu comprends pas

    Posté par  (Mastodon) . Évalué à 2.

    Toute personne qui ne comprend pas la soluce de cette première mission devrait probablement faire une partie de GameShell !

    Enfin, si la personne ne comprend pas pourquoi c'est cd chateau et non cd montagne, il y a peut-être autre chose à faire que jouer à GameShell, non ?

    Surtout, ne pas tout prendre au sérieux !

  • # dépendances

    Posté par  (site web personnel, Mastodon) . Évalué à 0.

    C'est fort de café de devoir installer NodeJS pour faire du shell, j'ai cru lire.

    Pour faire toutes les missions, il faut avoir :

    • un terminal avec bash
    • les paquets debian / ubuntu psmisc nano tree x11-apps

    Mais c'est tout aussi choquant pour moi qu'on ait besoin de X11 Apps,
    et je ne comprends pas pourquoi tu as besoin de killall/pstree/fuser,

    python3 (pour la génération des « parchemins » et la mission 33) et gcc (pour la mission 30) sont également nécessaires mais le joueur ne les utilise pas directement, et ils sont normalement installés par défaut.

    Sérieux ? ;-(

    “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: dépendances

      Posté par  . Évalué à 4.

      x11-apps, c'est pour avoir l'indispensable xeyes, qui est lancé dans la mission 17.
      Ce n'est pas stricto sensu une dépendance de GameShell.

      killall et fuser ne servent pas, mais on utilise pstree dans la mission 25.

      C'est pareil pour python3 et gcc : ils sont uniquement utilisés pour générer les missions 30 et 33. Si on veut, il est facile de faire une archive sans ces missions (avec la commande bin/archive.sh).

      Ceci dit, tu as raison. Je ne suis pas sûr que gcc et python3 soient présents sur une installation minimale. Je vais vérifier. (Pendant la première séance, les étudiants installent une VM Ubuntu, et ils sont probablement installés comme dépendances d'autres trucs…)

      python3 sert aussi à générer les boites autours des descriptions de missions, mais s'il n'est pas présent, on n'a pas les jolis parchemins !

      Ça pourrait être intéressant de tagger les missions qui sont compatibles POSIX, mais c'est un peu pervert, parce que bash n'est pas POSIX.
      Ça serait aussi bien d'avoir un truc plus formel pour gérer les dépendances de chaque mission. C'est dans un TODO…

      • [^] # Re: dépendances

        Posté par  . Évalué à 8.

        Une solution simple serait de sauter les missions pour lesquelles des dépendances manquent. Par exemple, si xeyes n'est pas installé, on obtient juste un message d'information disant que "xeyes n'ayant pas été trouvé, la mission 17 est annulée."

        • [^] # Re: dépendances

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

          Voilà une idée qui me plait mieux. <3

          Autre variante : ces missions avec des prérequis extras pourraient être des missions extra/bonus, des annexes facultatives qui ne sont activées que quand la dépendance est présente. Avec ça, pas de missions annulées ni de trous dans la numérotation.

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: dépendances

            Posté par  . Évalué à 5.

            Pourquoi pas, mais comme je vais continuer à l'utiliser en TP (vu le temps que j'y ai passé, je ne suis pas prêt de le changer celui là !), je préfère laisser toutes les missions qui m'intéressent !

        • [^] # Re: dépendances

          Posté par  (Mastodon) . Évalué à 2.

          Une solution simple ce serait de fournir un vagrantfile et un playbook ansible pour que l'étudiant puisse avoir l'environnement de TP sur une vm toute prête et configurée.

          • [^] # Re: dépendances

            Posté par  . Évalué à 1.

            Oulala. Ça fait un peu compliqué comme dépendance pour GameShell ! :)

            Mes étudiants arrivent avec une machine virtuelle Ubuntu. Ils doivent juste installer quelques paquets qui ne nécessitent en outre aucune configuration.

            Ceci dit, ça m'a donné envie de regarder : je n'ai jamais utilisé vagrant et ansible.

      • [^] # Re: dépendances

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

        Je te confirme que, la dernière fois que j'ai essayé (et ça remonte un peu), GCC n'est pas installé par défaut (sauf si c'est une dépendance d'un autre truc, mais si c'est l'installation minimale je ne vois pas trop…)
        Pour Python, je crois qu'il y a le strict minimum (le paquet python$X.$Y-minimal donc, sans autre module) si requis par les outils systèmes (Debian a quelques trucs utilisant ce langage, mais beaucoup beaucoup moins que CentOS/RHEL par exemple) À voir donc selon la partie (les modules) qui est utilisée pour la beauté des parchemins.

        Si, si, bash est compatible POSIX mais pas par défaut… Il y a des options à activer pour l'obliger à se comporter plus dans le sens de la norme que dans le sens de Korn. Il y a aussi des variables d'environnement qui permettent à certaines commandes de se conformer à ce qui est attendu du standard. Ce dernier cas s'applique aussi bien à des interpréteurs que divers utilitaires GNU quand on utilise $POSIXLY_CORRECT ;-)

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: dépendances

          Posté par  . Évalué à 2. Dernière modification le 28 mars 2021 à 11:57.

          C'est vrai, mais pour un truc comme GameShell, les parties non-POSIX de bash sont parfois bien pratiques.

          Je n'ai plus d'exemple en tête (probablement des substitutions sur les variables), mais je sais que j'avais commencé GameShell en essayant de rester compatible POSIX. J'avais abandonné parce que certains trucs devenaient assez lourds (et que j'étais un peu pressé).

          • [^] # Re: dépendances

            Posté par  . Évalué à 2.

            Personnellement, la fonctionnalité non-POSIX de bash que j'utilise le plus souvent, ce sont les array.
            C'est très pratique pour construire dynamiquement des listes de paramètres pour des commandes, ou pour itérer, sans risquer de problème avec les caractères spéciaux.

            Écrire des scripts shell non-triviaux et robustes sans array est juste pénible.

            • [^] # Re: dépendances

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

              Pareil :-) Je n'utilise que les tableaux quand je fais du bash/ksh, le reste du temps c'est du pure shell POSIX (le but étant d'avoir des scripts portables …et je m'en félicite chaque fois que je me retrouve dans le besoin d'utiliser un de mes scripts sur autre chose qu'un Linux récent et que ça marche sans rien changer)

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: dépendances

            Posté par  . Évalué à 2.

            L'objet du TP est-il d'apprendre à manipuler un shell interactif ou de scripter ? Pour les shell interactif je ne trouve pas qu'il soit pertinent de se limiter à posix.

            L'usage dans l'un et l'autre sont assez différents, l'exemple de base c'est qu'il n'est pas recommandé d'utiliser ls dans des scripts, qu'on va désactiver toutes les gestions des couleurs et les locales de tous les logiciels dont tu veut parser la sortie. Éventuellement tu voudra aussi faire un set -e (et tu ne fera jamais de set -e en interactif :p)

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: dépendances

              Posté par  . Évalué à 3.

              L'objectif est bien de manipuler un shell interactif, mais je soulevais la contrainte POSIX pour les sources de GameShell.

              Cependant, même dans un shell interactif, j'aime bien utiliser autant que possible utiliser des commandes POSIX. Je ne l'ai pas fait dans ce TP parce que l'objectif est de cacher le plus possible les parties "cracra" du shell. (Vous avez remarqué que je fais attention à ne surtout pas parler de guillemets ?)

              Et même une commande aussi simple que mv a une option non-POSIX : -t, pourtant bien pratique avec xargs.

      • [^] # Re: dépendances

        Posté par  . Évalué à 2.

        killall et fuser ne servent pas, mais on utilise pstree dans la mission 25.

        C'est dans psmisc, tout ça, pas dans x11-utils.

        Je ne suis pas sûr que gcc et python3 soient présents sur une installation minimale.

        Ils ne le sont pas.
        D'ailleurs, je n'ai que quelques applications qui me tirent python, dans la pratique je peux très bien le virer et conserver mon système avec mon player musical (mpd), mon lecteur video (mpv), mes navigateurs (vivaldi, firefox), mon MUA (claws) tout ce qu'il y a de plus fonctionnel.
        Bon, je triche: j'ai recompilé mpv et mpd pour virer le support de samba, qui dépend de python.
        En gros, j'ai besoin de python pour: scons, meson (qui sont utilisés pour compiler des jeux), zenmap, blender, zim et… c'est tout, en fait. Le seul outil qui me soit réellement utile fréquemment dans cette liste, c'est zim (que d'ailleurs je ne serais pas contre de remplacer, parce que python2+gtk2… et tant qu'a faire, remplacer pour un soft qui n'utilise ni gtk (et surtout pas gtk3!), ni python).

        Pour ce qui est de gcc, il n'est même pas installé dans une installation par défaut de Debian il me semble, même pas besoin d'être minimaliste.

        • [^] # Re: dépendances

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

          Oui, c'est moi qui ai cité les commandes de PSMisc que je connais et il a répondu que c'est pstree qui est utilisé dans le lot. Pour X11-Apps, il a répondu que c'est pour utiliser xeyes

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

        • [^] # Re: dépendances

          Posté par  . Évalué à 2.

          Ce qui m'avais enduit d'erreur, c'est que comme exemple de truc à installer sur leur VM, je donne idle3 aux étudiants lors du premier TP. Comme ils font du Python pour leurs cours de prog, ça me paraissait une bonne idée.

          Pour gcc, il est également installé lorsque je leur fais installer virtualbox-guest-additions-iso.

          Résultat, ils ont tous python3 et gcc au TP2, malgré une installation "standard" du Ubuntu.

          Et comme j'utilise moi même gcc et python3 (par exemple pour mes cours), je crois que je n'ai jamais eu de machine où ils n'étaient pas installés !

          En tout cas, on peut lancer GameShell sans eux, et dès que j'aurais testé un peu plus, on pourra gérer les dépendances de missions un peu plus facilement. (Lorsque les dépendances ne sont pas satisfaites, on aura un message, et la mission sera sautée.)

          • [^] # Re: dépendances

            Posté par  . Évalué à 2.

            Et comme j'utilise moi même gcc et python3 (par exemple pour mes cours), je crois que je n'ai jamais eu de machine où ils n'étaient pas installés !

            Python est assez omniprésent oui, je ne dis pas le contraire.

            J'essaie d'avoir un système python-free pour des raisons bien à moi, qui ne sont pas pertinentes ici, mais ça ne m'empêche pas de rester pragmatique et de l'utiliser quand même: je ne me vois pas me passer d'outils tels que zim, zenmap, gparted… tant que je ne leur trouve pas un remplaçant qui tienne la route, python me sera nécessaire.

            Je sais faire la différence entre l'idéal (le mien, pour mes raisons à moi) vers lequel je tend et le présent ou j'ai besoin de mes outils même s'ils ne cochent pas toutes les cases :)

            Le point de mon message était uniquement d'apporter des précisions.

  • # Essai et premiers retours

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

    J'adore. J'ai passé un bon moment à faire le TP. Merci beaucoup.

    Une PR pour améliorer divers points (principalement de l'orthographe) : https://github.com/phyver/GameShell/pull/13

    Remarques diverses :

    • le tgz ne devrait pas être dans le dépôt git (plus une question de principe qu'un vrai souci vu la taille, mais on a deux fois le code du coup, et il faut les synchroniser à chaque commit en théorie)
    • je m'attendais à trouver du shellcheck quelque part (dans le jeu ou pour valider le jeu)
    • bin/ ne contient pas des binaires (oui bon ok c'est très courant)
    • la mission 12 suppose une date à la française et pas à l'américaine (vu que tout est en français c'est logique, mais les dates ISO c'est mieux :))
    • [^] # Re: Essai et premiers retours

      Posté par  . Évalué à 2.

      Merci !
      À part quelques trucs (je garde "chaine" plutôt que "chaîne", et autres accents circonflexes), tout le reste est très bien.

      Pour le tgz, j'ai pas mal hésité, mais je voulais pouvoir faire lancer une partie sans cloner le dépot. Pour mon TP, je mets l'archive sur ma page web, mais vu la taille, j'ai décidé de mettre le tgz dans le dépot. (J'ai un pre-commit qui le regénère.)

      J'utilise (un peu) shellcheck sur les sources de GameShell à travers un plugin vim.

      Et pour les dates, c'est un choix pragmatique : je ne voulais pas avoir à expliquer la différence à tous les étudiants ! Comme on est sur une utilisation interactive, ça ne me dérange pas. (Ça serait différent si je leur demandais d'écrire un script.)

      • [^] # Re: Essai et premiers retours

        Posté par  (site web personnel, Mastodon) . Évalué à 3.

        Github, Gitlab, Gitea, et diverses forges permettent de récupérer facilement l'archive d'une version aux formats .zip ou .tar éventuellement compressé. De plus, quand le dépôt est public, l'adresse est prévisible… (donc on peut faire un coup de curl ou wget ou autre)

        Si les livrables sont différents de l'archive, il faut utiliser la fonctionnalité de releases de ces forges. On peut en plus avoir un pipeline qui génère automatiquement ces artifacts lorsqu'on crée des tags de version par exemple.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Essai et premiers retours

        Posté par  . Évalué à 1. Dernière modification le 15 avril 2021 à 01:06.

        en zip ou en .tar.gz, on peut direct les prendre sans en rajouter dans le repo.

    • [^] # Re: Essai et premiers retours

      Posté par  . Évalué à 4. Dernière modification le 27 mars 2021 à 13:18.

      la mission 12 suppose une date à la française et pas à l'américaine (vu que tout est en français c'est logique, mais les dates ISO c'est mieux :))

      Je ne comprends pas ce que tu attends par date à l'américaine. Aux USA, les dates s'écrivent 12/25/2021, ce qui, en plus d'être bizarre car le mois est avant le jour, n'est pas du tout de l'ISO (d'ailleurs les États-uniens se fichent habituellement pas mal des normes ISO).

      L'ISO c'est 2021-12-25, ce qui est logique et pratique pour le tri.

      https://xkcd.com/1179/

      • [^] # Re: Essai et premiers retours

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

        Je sais. Mais à cause des États-Uniens, quand tu vois XX-YY-ZZZZ tu dois te demander si c'est une date française ou américaine, alors que ZZZZ-WW-VV est clair. Et en plus dans un cours de shell, les dates ISO permettent les tris lexicographiques. Mais c'était une simple remarque, le choix qui a été fait est tout à fait logique (des dates « françaises » pour des étudiants étudiant en français).

        • [^] # Re: Essai et premiers retours

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

          Ce qui me semblerait plus logique c'est de reprendre les préférences des usagers… donc quand on est localisé en français avec ce format de date OK, sinon c'est pas top je trouve.

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

      • [^] # Re: Essai et premiers retours

        Posté par  (site web personnel, Mastodon) . Évalué à 0.

        Rien de bizarre ; il mettent l'élément le plus important en premier (je ne dis pas que l'année n'est pas importante, mais que c'est une forme de précision à l'écrit pour l'archivage.) Dans la vie de tous les jours, il est toujours bien de savoir de quel mois on parle et eux ils l'annonce d'emblée avant de dire de quel jour du mois il est question. « 12/25 » c'est « december the 12th » (ça se dit comme ça donc la forme écrite abrégée est cohérente.)
        Et ce n'est pas américain mais anglais tout court…

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Génial !

    Posté par  . Évalué à 3.

    J´en ferai la pub à mes étudiants!

  • # Petits retours

    Posté par  . Évalué à 4. Dernière modification le 29 mars 2021 à 10:12.

    Super idée. J'ai quelques retours, mais il faut vraiment les prendre comme des remarques. J'ai joué une vingtaines de missions et je te donne les points sur les quels ça a accroché pour moi, mais ça ne correspond pas forcément à ton besoin pour des TPs.

    • tu bidouille le ${HOME} (j'ai pas regardé comment c'était fait): j'ai l'habitude pour ce genre de choses de me créer un dossier dans /tmp pour jouer avec. Dans ce contexte faire un cd tout cours pour arriver à la racine n'est pas vraiment intuitif. D'autant que ma solution qui respectait les critères de la mission (2 ou 3 je ne sais plus aller à la racine puis ailleurs en 2 commandes) était validé. Je proposerais bien d'indiquer que le HOME est redéfini et de parler de 2 commandes cd les plus simples possibles
    • certaines mission s'intéresse plus à la manière qu'au résultat, c'est dommage quand la manière n'est pas optimale. Par exemple pour montrer les lignes 9 à 11 d'un fichier moi je fais awk '9 <= NR && NR <= 11' fichier (j'ai volontairement évité de regarder les aides en me concentrant sur les missions et comment moi je ferais)
    • la mission sur l'alias journal demande à utiliser nano avec mon vim je pouvais pas le valider :$
    • j'ai eu du mal à comprendre l'attendu dans la mission sur la falsification du tableau
    • j'ai pas compris les missions sur le calcul mentale… (je crois que c'est par là que je me suis arrêté)

    Je te conseil de créer un tag pour la version qui est joué par tes étudiants d'une année, ça aide à la traçabilité pour toi et pour les étudiants.

    Je finirais dans la journée les missions et je regarderais le code voir si j'ai d'autres remarques. Merci pour le partage

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Petits retours

      Posté par  . Évalué à 4.

      Merci pour ces retours.

      • pour le $HOME, c'est un choix que j'assume. C'est assez naturel dans ce contexte que le répertoire personnel, ou "point de départ" soit à la racine du jeux. Je n'en parle qu'à l'oral et qu'aux étudiants qui connaissent. Ajouter un message la dessus dans le gash show va plus perturber les débutants qu'aider les connaisseurs.

      • pour les missions 23, c'est vrai que c'est un peu artificiel. L'objectif explicite est surtout de faire une première redirection de commandes. (Je n'ai encore jamais eu d'étudiant qui connaissait awk !)

      • pareil pour nano. Même si tout le monde sait bien que vim est le meilleur éditeur de texte de l'univers, je ne voulais pas imposer ça aux étudiants. nano a le mérite d'avoir la liste des racourcis clavier affichée par défaut, ce qui me simplifie la tâche.

      • Je suis d'accord avec toi sur la mission de falsification du tableau. C'est très artificiel, et je n'ai jamais eu besoin de faire quelque chose comme ça en vrai. Elle va probablement disparaitre un jours.

      • Et pour le calcul mental, essaie de faire gash check pour voir ce qu'on te demande. (Ne réfléchis pas trop sur la première mission.)

  • # À tester

    Posté par  . Évalué à 1.

    Moi qui cherchait à introduire les bases de l'utilisation d'un OS en CLI, je suis content.

    Merci

Suivre le flux des commentaires

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