 |
Vendredi 06 juin 2025 - 12:20 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Effacements sauvages avec #?
Des fichiers "script" interactifs, pour quoi faire ? Oyez, bonnes gens, l'histoire qui suit :
Il y a quelques millénaires, au fond d'une caverne particulièrement caverneuse, Frédéric "El Yéti" Autechaud était assis devant son Amigouth (l'Amigouth était un ancêtre de l'Amiga, plus gros, avec une fourrure à longs poils et une imprimante rupestre à projection fine ; on peut voir des dessins remarquables exécutés par cet ensemble dans des lieux comme la grotte de Lascaux par exemple (Bruce Lepper : il y en a pas mal dans les grottes d'Eymet, aussi). Pour mieux appréhender certains éléments du contexte archéologique de cet épisode, veuillez vous reporter à la Rubrique-à-Brac, tome 5, page 50, où vous verrez en particulier un portrait de Frédéric Autechaud, pétrifiant de réalisme).
Frédéric Autechaud donc se trouvait face à un répertoire nommé BD, qui contenait les fichiers Tintin, Tintin.info, Tintin.doc, Tintin.doc.info, Haddock et Haddock.info. Comme il ne savait pas lire (mais nous savons qu'il dessinait très bien), il n'avait que faire du fichier Tintin.doc, qu'il se proposait de virer, et l'icône avec. Il se préparait donc à taper :
| WB0.05:BD> delete #?doc#? |
Mais à ce moment précis, sa charmante compagne, qui s'était mise en tenue (si on peut dire) pour aller prendre son bain de soleil à l'entrée de la grotte, eut une pensée émue pour son compagnon qui suait devant son Amigouth (note de l'Amigouth : et moi, alors ?) et alla chercher au frigo un Yop fraise qu'elle apporta à Frédéric Autechaud. Ce dernier, complètement déconcentré par ce spectacle délicieux, tapa en fait :
| WB0.05:BD> delete #? doc#? |
(il y a donc un espace avant "doc")... avec pour résultat :
|
WB0.05:BD/Tintin.info Deleted WB0.05:BD/Tintin.doc Deleted WB0.05:BD/Tintin.doc.info Deleted WB0.05:BD/Haddock Deleted WB0.05:BD/Tintin Deleted WB0.05:BD/Haddock.info Deleted |
De rage, Frédéric Autechaud envoya le Yop fraise à la tête de son amie, et fila un énorme coup de massue à l'Amigouth, avec les résultats (prévisibles) suivants : crise de larmes, une tache sur la moquette en poils d'Atarouth (l'Atarouth, déjà, était monotâche, ce qui faisait que son poil était précisément recherché pour la moquette), et une énorme touche dans la massue. Sans compter les précieux fichiers perdus, ou pas tout à fait, car Frédéric Autechaud avait une sauvegarde, vous auriez dû vous en douter rien qu'à la profondeur de son regard, si vous avez trouvé le portrait dont auquel j'ai causé plus haut.
Passons sur la scène de réconciliation complètement banale qui suivit ; quelques laps plus tard, nous retrouvons Frédéric Autechaud devant son répertoire reconstitué, et qui tape :
| WB0.05:BD> delete #?doc#? |
...ce qui le débarrasse du fichier inutile Tintin.doc, de l'icône Tintin.doc.info ; mais l'Amigouth n'était pas d'humeur à pardonner quoi que ce soit, et les fichiers Haddock et Haddock.info disparurent aussi.
Morale de l'histoire
1. La commande "delete" utilisée avec "#?" peut se révéler ravageuse. La dernière fois que ce genre de mésaventure m'est arrivée, dans un répertoire de disque dur contenant une vingtaine de fichiers, je me suis entendu dire bêtement cinq fois de suite "et merde..." au lieu de faire Ctrl-C pour arrêter le massacre.
2. Ayez des sauvegardes.
3. Si vous effacez des fichiers par erreur, rien n'est perdu tant que vous n'écrivez plus sur la disquette. Prenez un bon utilitaire comme DiskX (en téléchargement sur DEEP ou sur Fish 71 (c'est une ancienne version) ou sur T-Bag #16, ou encore ailleurs), la doc vous dit comment restaurer un fichier perdu si vous vous souvenez de son nom exact. Il y a aussi un utilitaire nommé "Undelete", qui ne marche que pour les disquettes (DiskX marche aussi pour les disques durs), disponibles sur Fish 154.
4. Prenez l'habitude d'ouvrir votre fenêtre Shell à tout l'écran ; d'abord on dort bien mieux la fenêtre grande ouverte, ensuite cela vous donnera plus de chances de pouvoir noter le nom des fichiers perdus.
5. Jamais, au grand jamais, n'utilisez DiskDoctor, une commande du répertoire C:. Cette commande s'est un jour échappée d'une poubelle mal fermée, et c'est bien dommage. Personnellement, et je ne suis pas le seul, j'ai toujours retrouvé une disquette plus bousillée que réparée par DiskDoctor. A partir d'une petite erreur ("read-write error" sur un fichier), DiskDoctor a l'habitude de fiche en l'air une bonne partie de la structure de la disquette. L'honnêteté m'oblige à ajouter que ce n'est pas le seul programme capable de faire des ravages. Le système d'écriture des fichiers d'AmigaDOS est enclin à la génération de catastrophes en avalanche. Alors, avant de toucher à une disquette qui a une malheureuse erreur de lecture/écriture, par exemple, s'il y a quelque chose de précieux dessus, adressez-vous à quelqu'un qui connaît le sujet.
Ask à la rescousse
Connaissant les dangers de l'utilisation de "Delete" avec "#?", nous allons nous créer une commande qui va nous demander notre avis avant de faire des bêtises. Nous l'appellerons par exemple "DelPat" (de "Delete" et "Pattern"). Pattern signifie "motif" dans le sens du motif d'un dessin ; ce terme désigne ici une chaîne de caractères sur la base de laquelle une opération va s'effectuer sur une série de fichiers, dont le nom contient ladite chaîne.
Comme d'habitude, nous la créons par ED, sans oublier de lui ajouter l'attribut "S" (voir le mois dernier).
Voici ce que ça donne :
|
.key fichiers list <fichiers> nodates echo "Sont-ce bien la les fichiers que vous voulez détruire (Y/N) ?" ask [N] if not warn skip sortie endif delete <fichiers> lab sortie |
Comme d'habitude, voyons ce que ça donne, et pourquoi. Si nous tapons :
| WB1.3:BD> delpat #?doc#? |
La commande "List" liste les fichiers contenant la chaîne "doc". Nous voyons immédiatement que les fichiers Haddock et Haddock.doc sont candidats à la destruction, ce qui n'arrivera pas si nous tapons :
| WB1.3:BD> delpat #?.doc#? |
Si nous faisons la première erreur de notre conte paléolithique en insérant un espace, nous aurons un message "Bad args: too many arguments" car ce que nous avons tapé ne correspond pas à une syntaxe acceptable par List. Nous voyons que quelque chose ne va pas, le dommage a été évité.
Ensuite, nous affichons par "Echo" un message qui nous avertit de ce que la commande Ask attend une réponse. En fait, l'interaction de Ask est assez limitée, puisqu'elle ne comprend que "oui" ("Y") ou "non" ("N" ou n'importe quoi ou simplement la touche "Entrée").
La syntaxe en est :
| Ask <prompt> |
...où "prompt" est n'importe quel signe cabalistique ou chaîne de caractères de votre choix, et qui s'affichera en attendant votre réaction. Nous avons mis [N], cette formulation classique suggérant un choix par défaut de la réponse "non" (la plus sûre), obtenue tout simplement par pression sur "Entrée".
Selon que vous avez tapé "yes", ou simplement "Y" (en majuscules ou minuscules ou en mélangeant les deux), ou bien "N" (etc.) ou simplement un "Entrée", Ask met à 5 ou à zéro une variable interne qui s'appelle toujours "Warn".
La ligne suivante teste si Warn vaut 0 ou pas. Si Warn vaut 0, c'est que vous avez répondu par la négative, et on sort si vous avez donné une réponse affirmative, Warn prend la valeur 5 et on passe à l'exécution de Delete avec la chaîne de caractères que vous avez spécifiée après DelPat.
Et voilà. Cette réalisation de notre commande DelPat n'est certainement pas à considérer comme ce qu'il y a de plus sophistiqué en matière de script interactif, mais elle a le mérite d'être simple, et même utilisable. A vous maintenant de l'essayer en vous créant un répertoire avec des fichiers à détruire, et un répertoire contenant les copies de ces fichiers de manière à pouvoir en une seule commande Copy reconstituer votre répertoire d'essai après chaque usage de DelPat et des versions plus performantes que vous ne manquerez pas d'écrire à titre d'exercice.
Enfin, le domaine le plus classique d'application des fichiers script est celui des startup-sequence.
Avec ce que vous savez déjà, vous pouvez commencer à bidouiller vos propres startup-sequence, le sujet a été traité assez largement dans les colonnes d'A-News (ici et <là, et il y a beaucoup de bonnes informations là-dessus dans la doc actuelle de l'Amiga.
Execute
Me voilà tout soudain pris d'un remords parce que je ne vous ai pas parlé d'Execute. Tout d'abord, puisqu'un fichier script muni de l'attribut "S" et situé dans un "path" préalablement défini (voyez le début de l'article précédent), est exécutable de partout rien qu'à l'appel de son nom, on pourrait croire qu'on n'a plus besoin de la commande Execute.
Ce serait une erreur, car ce qui précède ne vaut que si l'on se trouve dans une fenêtre Shell. Tant que le programme Shell-Seg n'est pas résident (ne vous en faites pas, le mécanisme de lancement des fenêtres Shell fourni dans le Workbench 1.3 s'en charge), un fichier script, même muni de l'attribut "S", doit être lancé par Execute. Il y a au moins un cas de figure : si vous n'avez pas la ROM 1.3, et si vous vous faites sur disquette une micro startup-sequence qui se contente d'appeler le disque virtuel RAD: (sur lequel vous avec copié ce qu'il faut), puis de lui passer la main par un mécanisme comme ceci :
Startup-sequence sur la disquette de démarrage :
|
mount rad: cd rad: execute rad:radstartup |
...ce qui accélère substantiellement le démarrage à chaud, la commande Execute est indispensable car la disquette de démarrage ouvre initialement un CLI et non un Shell.
Un corollaire de ceci est que, pour des fichiers script importants, Execute ouvre dans le répertoire T: un fichier temporaire qui s'appelle "Command-T-xx" où "xx" est un numéro d'ordre.
Comme pas mal d'éditeurs mettent aussi des fichiers temporaires dans T:, veillez soit à vider le répertoire T: de votre disquette de démarrage, soit, quelque part dans votre startup-sequence, à faire :
|
cd ram: makedir ram:t assign T: ram:t |
...ce qui aura l'avantage de vider le registre T: à chaque démarrage puisque le contenu de RAM: disparaît alors. Je vous dis ceci pour vous éviter la tentation d'enlever Execute de vos startup-sequence, en pensant que ça marchera si le fichier lancé par Execute a son attribut "S" de mis. Cela dépend du fait que le Shell a été lancé préalablement ou non.
Pour ceux qui ont le Workbench 1.3 et qui n'iront par trifouiller leurs startup-sequence, vous pouvez oublier l'existence d'Execute.
La prochaine fois, nous parlerons de Run et des tâches qui s'exécutent en arrière-plan (background). C'est là qu'on sera content d'avoir un descendant de l'Amigouth !
|
