Re: Fwd: Re: [EDUC] Utilisation Campus - Prof Expert

[Patrice Pillot <patrice.pillot AT teletopie.net>]

Frederic Roux a écrit :
> Le Thursday 04 December 2008 22:12:41 Patrice Pillot, vous avez écrit :
>> [fred@localhost ~]$ cd /media/DSK_USB_EXT
>> [fred@localhost /media/DSK_USB_EXT]$ ./ProfExpert\ pour\ Linux.sh
> Génial ! Ça a marché ! Merci, c'est bien la première fois que je réussi une 
> ligne de commande (si si, il y a des gens sous GNU-Linux qui ne mettent 
> jamais les mains dans le cambouis ;-) )
> Bon, il me reste plus qu'à réussir à le refaire.

Les mésaventures de Frédéric tombent à point nommé, si j'ose dire. Je
m'apprétais, suite à la réponse d'Aimé et à son incompréhension
manifeste de mes propos, et afin de me faire comprendre par des exemples
plutôt que par des discours, à créer une histoire fictive d'un
utilisateur "ordinaire" de l'informatique confronté à une succession de
ces (pas toujours si) menus problèmes qui empoisonnent (et parfois plus
encore) la vie de millions de gens qui se sont un jour retrouvés avec
une souris dans une main et un clavier dans l'autre sans aucune
formation véritable /à/ l'informatique. La réponse de Frédéric (qui pour
un problème technique n'a pu être diffusée directement sur la liste) va
donc m'éviter de créer un scénario de toute pièce.

Je me suis amusé à reconstituer quelles connaissances de base ont fait
défaut à Frédéric pour qu'il parvienne à résoudre seul son problème (il
y a sans doute des oublis ou des approximations de vocabulaire ici où là
mais vous comprendrez le sens la démarche).

1) Premier problème rencontré : Le clic sur l'icône d'un script de
commandes a provoqué l'affichage du contenu du fichier dans un éditeur
et non l'exécution dudit script.

Analyse : il fallait comprendre que le gestionnaire de fichier employé
ne reconnaissait pas ce fichier comme un programme exécutable et
l'associait donc à une application autre, en l'occurence un éditeur de
texte (au passage on a eu de la chance car le gestionnaire de fichier
aurait pu simplement lui dire "fichier de type inconuu, choisissez
vous-mêmes tout seul comme un grand avec quel programme utiliser ce
fichier"). La solution à apporter à ce problème consistait donc à
"forcer", d'une manière ou d'une autre, l'exécution du script.

Compétences nécessaires à la résolution du problème :
- savoir que derrière l'icône se cachait un fichier contenant des
instructions exécutables par l'ordinateur (problème concret)
- savoir que le clic sur une icône de ce type de fichiers a normalement
pour effet de provoquer le chargement de ces instructions en mémoire
puis leur exécution (mécanisme sous-jacent)
- savoir que c'est la fonction du "gestionnaire de fichier" que
d'interpréter le clic de l'utilisateur comme une demande de chargement
et d'exécution du programme (programme "médiateur").
- reconnaître l'extension du fichier qui indiquait qu'il s'agissait d'un
script shell
- savoir qu'un script est à la fois un fichier texte et un programme
- connaître une autre solution pour provoquer le chargement et
l'exécution du script ; il y avait ici deux solutions : soit forcer le
gestionnaire à exécuter le script et non à le charger (solution que je
n'ai pas réussi à mettre en place rapidement), soit lancer le script en
ligne de commande (je confesse que cette méthode m'est plus habituelle)
- cette dernière solution nécessitait de savoir ce qu'était un chemin de
fichier (pathname)
- donc de savoir ce qu'est un système de fichier,
- de savoir identifier le chemin de fichier du script
- de connaître les contraintes syntaxiques particulières de
l'interpréteur de commande pour qu'il accepte d'exécuter un programme
qui n'est pas dans le PATH de l'utilisateur (soit le chemin complet,
soit un chemin relatif commençant par "./")
- et donc savoir ce qu'est le PATH
- savoir que certains caractères comme les espaces doivent être protégés
dans les noms de fichiers

2) Problème rencontré : l'exécution du script depuis la ligne de
commande provoquait l'affichage d'une erreur faisant état d'un fichier
innaccessible dont le nom était donné par le message d'erreur.

Analyse : il fallait comprendre que l'interpréteur java cherchait à
accéder au fichier jar identifié par un chemin relatif au script de
commande. La commande que j'avais suggérée à Frédéric était lancée
depuis son répertoire utilisateur (puisque lancée juste après
l'ouverture d'une session shell). La solution consistait donc à relancer
la commande depuis le répertoire du script (si j'avais été plus attentif
j'aurais pu éviter cette étape à Frédéric en lui indiquant tout de suite
la bonne manip)

Compétences nécessaires à la résolution du problème :
- avoir des rudiments d'anglais informatique
- accepter de lire les messages d'erreur et d'essayer de les comprendre
- savoir que le mot "java" désignait une commande (peut importait ici de
savoir qu'il s'agissait du lanceur/chargeur java même si ça aidait, le
plus important était la connaissance de la syntaxe d'une ligne de
commande : nom_de_commande [ argument ... ])
- savoir corollairement reconnaître dans la chaine
"ProfExpert/App/cp/cp.jar" un paramètre utilisé par la commande "java"
- savoir reconnaitre dans ce paramètre un nom de fichier
- voir que ce fichier était identifié par un chemin relatif
- connaître donc la différence entre chemin absolu et chemin relatif
- comprendre que le script de commande devait donc être invoqué depuis
le répertoire qui permettrait une résolution correcte de ce chemin relatif.
- donc avoir acquis la notion de répertoire courant ($CWD)
- savoir utiliser la commande "cd" pour changer de répertoire courant

J'imagine que pour certains celà représente une quantité énorme
d'informations. Pourtant non. Leur apprentissage nécessite certes des
efforts (mais incomparablement moindres que ceux nécessaires à la
maîtrise de la relation de Chasles, par exemple, je peux vous l'assurer)
mais n'a rien d'extraordinaire et est à la portée de tout le monde, et
j'insiste sur ce dernier point.

Surtout, ce qui m'importe ici c'est que ces problèmes rencontrés par
Frédéric sont l'archétype de ceux rencontrés par des millions de
personnes dans leur usage quotidien de l'informatique : difficultés
d'accès à des documents sur un support amovible (le cas s'est encore
posé hier sur la liste de diffusion du GUL toulousain pour un
utilisateur qui n'arrivait pas à utiliser la version de Blender placée
sur le livre d'Olivier consacré à ce logiciel), problèmes avec des
pièces jointes dans les courriers électroniques, avec des pages web dont
le contenu semble illisible, avec des diaporamas récalcitrants, problème
pour envoyer un courrier (n'est-ce pas Frédéric ;-) - mais cette fois-ci
tu ne pouvais rien faire, c'est une erreur du serveur de l'april)...

J'affirme (en assumant ce qu'il y a de péremptoire à le faire) qu'aucun
élève ne devrait terminer sa scolarité secondaire sans posséder les
connaissances nécessaires à la résolution de ce type de problèmes. Le
fondement de ma démarche est donc de dire : il faut que les dispositifs
nécessaires à l'enseignement de ces connaissances soient mis en place
par l'éducation nationale, et la première chose à faire pour celà c'est
de commencer par libérer une place dans les programmes scolaires du
collège et du lycée pour cette formation qui est une formation /à/
l'informatique, avant d'être une formation /avec/ l'informatique (même
si nécessairement des machines et des logiciels seront utilisés par les
enseignants et les élèves pour l'acquisition de ces connaissances). Le
choix (et même la détermination des critères de choix) des outils
(logiciels et pédagogiques) à utiliser pour cette formation doit venir
*après* la fixation de ces programmes (scolaires). C'est en ce sens que
je parle d'une erreur méthodologique grave dans un de mes précédents
messages : parler d'outils sans parler au préalable de syllabus c'est
tout simplement mettre la charrue avant les bœufs, c'est comme de
demander un tournevis alors que l'on risque d'avoir un clou à planter.
Pour l'instant l'urgence me semble donc être de convaincre les décideurs
du ministère de l'éducation nationale d'adopter ce point de vue.

Par ailleurs, afin qu'on ne se méprenne pas sur mes propos, je ne
prétends pas que c'est là l'alpha et l'oméga de l'enseignement de
l'informatique à l'école. Aimé souligne avec raison qu'il est également
important de doter les élèves des connaissances qui leur seront
nécessaires pour garder le contrôle sur ce qu'il appelle avec une
certaine justesse leur identité numérique. Et encore au-delà plusieurs
intervenants ont sur cette liste souligné la nécessité d'éveiller les
consciences des enfants aux richesses tout comme aux pièges de
l'information disponible via l'Internet.

Mais il y a entre la formation aux fondements de l'informatique que
j'appelle de mes vœux et ces formations-ci un rapport dialectique qui me
semble similaire à celui qui existe entre l'enseignement de la grammaire
et du vocabulaire et celui de la littérature : l'étude de cette dernière
(qui est la seule de véritable importance !) sera à tout jamais limitée
par les compétences purement langagières de l'élève !

Que Frédéric me pardonne de l'avoir ainsi mis sur le devant de la scène,
tout le monde comprendra qu'il n'y a bien sûr ni volonté de le pointer
du doigt, ni l'ombre du moindre reproche dans mes propos à son égard.

Cordialement,

pp