DrShell : Différence entre versions

De Nybi.cc
Aller à : navigation, rechercher
 
Ligne 109 : Ligne 109 :
  
 
[[Category:Projet]]
 
[[Category:Projet]]
[[Category:Projet_en_cours]]
+
[[Category:Projet_terminé]]
 
[[Category:Software]]
 
[[Category:Software]]

Version actuelle en date du 6 septembre 2016 à 17:22

Présentation du projet

DrShell est un projet visant à réaliser un outil pour aider à comprendre comment marche le CLI (l'interface textuelle classique sous unix). Mais oui mais oui, c'est un projet du lab (même s'il est potentiellement un peu virtuel), pas un projet à propos du lab pour aider à son bootstrap. Désolé, c'était trop pressé alors on abuse de l'infra web du lab honteusement.

Tout part de la constatation qu'enseigner le shell, c'est dur. Le rapport avec le lab? Ben partager le savoir. Et ca va ptet tourner en objets physiques pour faire comprendre les concepts, à voir.

Objectifs 30,000 feets

On veut donc mettre en place des moyens expliquant le fonctionnement des commandes d'une ligne comme on en utilise en console, de façon à

1. motiver les spectateurs/utilisateurs à apprendre cette interface

2. leur permettre comprendre par une expérimentation personnelle et directe comment ca marche

Oui, on parle de trucs comme ceci (en moins con, cet exemple est pourri)

 grep -h TODO `find -name '*.txt'` | sort -n

Identifier les verrous pour les dépasser

Comme expliqué dans le lien ci-dessus, il semble y avoir deux types de complexités à surpasser pour maîtriser le CLI : savoir que chaque commande existe quand on a besoin de l'outil correspondant, les options et leurs actions d'une part, et comprendre la structuration d'une commande shell en elle même. C'est une forme de programmation assez spécifique (data flow), et c'est déroutant pour les débutants.

On se dit qu'il faut aider les débutants à se construire une image mentale de comment ça marche afin qu'ils puissent comprendre le truc. Pour la faire courte, l'idée en cours est de faire un support visuel (interactif ou non) facilitant l'acquisition de cette image mentale par des debutants.

Motivations pour l'utilisation du CLI

  • tâches facilement automatisables
    • alias dualscreen pour afficher mon bureau sur deux écrans
  • facilité pour trouver de l'aide sur internet (il est plus facile de donner une commande à copier-coller que d'expliquer comment utiliser une interface graphique)
  • pas besoin de devoir tout réapprendre quand il y a une mise-à-jour. Quand une interface graphique change on se retrouve facilement perdu.
  • plus simple pour accès distants (pour aider quelqu'un par ssh par exemple)

Outil interactif de dissection des oneliners

Paul a fait un truc en javascript+html ici. L'idée est d'animer étape par étape le déroulement d'un oneliner pour le dissequer. C'est pas fini, c'est améliorable, mais l'idée est là. La conclusion est que cette vizu semble prometteuse (à nous au moins), mais que javascript+html c'est pas adapté : faut recoder toutes les commandes qu'on veut rendre dispo ce qui est une tâche dantesque.

Polux a également fait un script un peu comparable en haskell (lien?), avec moins de rendu graphique. De même, haskell semble pas forcément adapté à ce qu'on veut vu qu'il faut recoder les commandes à la main.

Peut-être que la bonne solution serait un truc en perl ou python, les expérimentations doivent continuer pour le déterminer.

Support visuel introductif

On se dit actuellement que le mieux est peut-être de faire un petit film pour expliquer les grandes lignes de ce qu'est le shell et présenter les grandes lignes de ce qu'un oneliner contient. Conscients de nos limites en graphisme / design and co, on ne vise absolument pas quelque chose de beau / attirant. On vise juste un moyen efficace de passer le message, dans l'espoir qu'on trouvera ensuite des gens pour nous aider à le rendre un peu moins moche. On vise un truc à la limite du story board, pour l'instant.

Etapes possibles du film

Introduction

Comme je suis universitaire, j'aurais tendance à commencer par poser le contexte en passant par l'histoire du truc. C'est pas forcément une bonne idée, ceci dit, mais bon. Mon idée est de dire :

- sous unix, presque toute l'info est stoquée sous forme de fichier texte car les anciens voulaient pouvoir tout modifier facilement sans se faire chier.

- Au passage, c'est assez différent de l'esprit windows où les choses ne peuvent être modifiées qu'en passant par l'interface clicodrome prévue par le vendeur. On n'a pas accès facilement à l'info stockée dans la base de registres, sauf à passer par l'interface que le vendeur veut bien que vous preniez. Dire cette idée risque de troubler le message : on parle de CLI ou de logiciel libre??

- au bout d'un moment, les anciens ont trouvé ca répétitif et fastidieux, alors ils ont cherché à automatiser les ptites tâches de la vie de tous les jours : trouver le fichier qui contient une info en particulier, le mass renaming, le mass search/replace, etc. Les one liners et les scripts shell sont nés de ceci. On peut vouloir faire un peu de biblio pour vérifier cette motivation historique, ca évitera de dire n'imp, ptet

Motivation

Le top serait de trouver un fil rouge, une commande difficile à faire en clicodrome, mais bien plus simple en CLI. C'est assez difficile à trouver car mon environnement de travail perso est tout en fichiers textes donc j'écris régulièrement des oneliners, mais les windozeurs et maceux ont des fichiers opaques et donc moins besoin de telles choses. Quelques idées en vrac tout de même:

- mon exemple classique en cours est un mass renamer, car je garde un souvenir ému d'un ami qui a passé une soirée à renomer tous les fichiers DCN0xxx.jpg en Noel_2010_xxx.jpg. Il paraît qu'il y a maintenant un mass renamer dans windows 7, mais on me souffle dans l'oreillette que c'est assez pourri comme interface.

- On peut faire sentir la puissance du cli en faisant un mass renaming expérimental : « Alors, vous allez renommer les photos... »

Tu prends 10 photos et ils font le renomage à la main en clickodrome. C'est juste assez pénible pour qu'avec une série de 10 autres photos le renomage en cli prenne tout son sel.

- dans ubunchu, ils ont une multitude de fichiers à retraiter et en font un csv à lire dans exc^W^W libreoffice.

- on peut prendre des idées dans le quotidien (fantasmé) des sysops de ces ages immémoriaux, dans l'esprit de l'histoire des pingouins. Genre tes utilisateurs sont des étudiants, et tu dois déplacer leurs comptes quand ils passent d'une année à l'autre ou qu'ils redoublent. danger, les systèmes universitaires diffèrent d'un pays à l'autre, ca serait dommage d'être franchouillard pour rien.

- grep -> je sais que j'ai écrit le numéro de téléphone de sophie dans un fichier, mais où? (ah merde, elle s'appelle sophie ou sylvie, déjà?) Des prénoms masculins permettent d'éviter les clichés sans que ca change rien.

- on peut faire des choses un peu plus avancées, comme de l'aspiration de sites web avec modifications à la volée ou quoi.

- un des verrous est le vocabulaire. Il faut au début expliciter les termes dans un vocabulaire courant pour faciliter le « hash concept/expressions. »

Par exemple « entrée/sortie standard » on peut ajouter « normale » ou « ordinaire » ou « par défaut ». Mais pour faciliter l'association concept/expressions, à chaque fois que le rookie emploie le mot de substitution il faut le reprendre avec l'expression consacrée.

- Pour le débutant, on peut faire la différence entre les commandes qui modifient l'univers et celles qui « regardent » l'univers :

un "ls" ou un "cat" ne change pas l'univers, un "cat toto > tata", si.

- On peut proposer la création d'un fichier texte "hello_world" qu'un élève cache dans l'arborrescence de fichiers sous win et sous nux, puis : le premier qui l'imprime a gagné ! (prévoir une chupa-chups ;-))

L'idée est de trouver des exemples pas trop compliqués dans le parsing de la ligne de commande mais qui apporte un gain de temps maximal dans la réalisation de la tache.

Je crois beaucoup à la représentation de l'univers avant et après une commande en utilisant les couleurs. L'ideal étant de pouvoir le représenter aussi en cours de changement, mais là c'est chaud à coder dans le cas général.

Présentation

C'est à ce moment qu'on explique que l'une des lignes directrices d'unix, c'est d'avoir une multitude de petites commandes qui font chacune une seule chose, mais la font bien, plutot qu'une grosse usine à gaz qui fait tout en pas forcément terrible (qui a dit "Word" au fond?). On en profite pour présenter la demi-douzaine de commandes les plus classiques (ls, grep, find, en gros), et expliquer comment avoir plus d'info sur chacune d'entre elles (man).

Exemples

Et c'est là qu'on fait des choses comme l'exemple de Paul, dont un lien est donné plus haut. On fait des ptites commandes simples que l'on disseque graphiquement, puis des exemples un peu plus complexes, et ainsi de suite.

Experimentations

À la fin, on donne un environnement ouvert où chacun peut expérimenter avec les one liners. On peut vouloir faire des exo progressifs où faut écrire des commandes de plus en plus complexes, et où on peut tester interactivement si on a répondu juste ou pas. Quelque chose comme la Java Learning Machine, mais pour le scripting shell, pas pour Java.

Activité physique possible

On peut envisager des séquences à organiser avec des élèves, dans l'esprit de Computer Science Unplugged où ils se passent des "fichiers" (en fait des fiches cartonnées) en fonction de leurs rôles dans le tube de commandes. Idée à fouiller, même si je sais pas si on ira loin avec.

Quelques liens source d'inspiration

ubunchu épisode 2 un manga spécialisé dans la vulga d'ubuntu, sur le thème des CLI. Pas très pointu techniquement, mais graphiquement intéressant (?) En tout cas, ils ont le même objectif.

L'histoire des pingouins un roman un peu délirant qui peut servir d'inspiration pour l'ambiance des scènes avec les grands anciens, au début

Why shell scripting motivations de l'utilisation du shell

Quelques cheat sheet: [1] [2] [3] [4]