Obligement - L'Amiga au maximum

Samedi 20 avril 2024 - 00:43  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

Actualité (récente)
Actualité (archive)
Comparatifs
Dossiers
Entrevues
Matériel (tests)
Matériel (bidouilles)
Points de vue
En pratique
Programmation
Reportages
Quizz
Tests de jeux
Tests de logiciels
Tests de compilations
Trucs et astuces
Articles divers

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des jeux Amiga

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z,
ALL


Trucs et astuces

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Glossaire

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


En pratique : Les fichiers script (AmigaOS 1.x)
(Article écrit par Pierre Ardichvili et extrait d'A-News (Amiga News) - septembre 1989)


Nous allons cette fois étudier les fichiers "script", ce sera une manière de mettre un certain nombre de commandes au travail et donc de mieux les connaître.

Tout d'abord, un fichier script est un simple fichier constitué d'une suite de commandes normalement trouvées dans le répertoire C, mais ces commandes peuvent être n'importe quel programme directement exécutable, à condition qu'il "rende la main" au Shell, c'est-à-dire qu'une fois exécuté, ou lancé si c'est un programme qui restera résident, on retrouve l'invite de commande du Shell et qu'on puisse continuer à envoyer d'autres commandes dans la même fenêtre, et qu'elles s'exécutent. J'appelle ces programmes des programmes "bien élevés".

Bien élevé

Exemple :

2.WB1.3> echo "Bonjour"
Bonjour
2.WB1.3>

La commande "echo" est bien élevée.

En fait, les programmes qui finissent une tâche avant qu'on ne demande autre chose, sont en général par définition bien élevés, ils rendent la main au Shell après avoir fait ce que l'on demandait ; il y en a d'à moitié bien élevés qui demandent un retour de chariot pour faire réapparaître l'invite de commande.

C'est parmi les programmes qui fonctionnent, en permanence que l'on trouve les programmes mal élevés.

Mal élevé

Un exemple de programme intéressant mais mal élevé : PerfMon. Vous le trouverez sur votre disquette Extras 1.3, tiroir "Tools". Imaginons que vous l'ayez copié dans le répertoire "System" de votre Workbench 1.3, faisons :

3.WB1.3> system/PerfMon

Vous voyez apparaître une petite fenêtre dans laquelle sont données en permanence des informations sur le fonctionnement du système : temps d'occupation du processeur, mémoire disponible.

Mais votre fenêtre Shell est bloquée ; vous pouvez y écrire ce que vous voulez, cela s'affiche, mais rien ne se passe. Ce n'est que lorsque vous aurez cliqué dans le gadget de fermeture de PerfMon que l'AmigaShell essaiera d'interpréter et d'exécuter ce que vous avez tapé. La plupart du temps d'ailleurs, cela se soldera par un message :

2.WB1.3> unknown command

Un exemple de programme bien élevé (c'est un programme du domaine public) : VirusX. Imaginons que vous l'ayez mis dans votre tiroir "Utilities", faisons :

2.WB1.3> utilities/VirusX

La micro-fenêtre de VirusX apparaît dans le haut de l'écran, le programme est là, il surveille en permanence toute disquette introduite dans le lecteur, mais aussitôt chargé, il rend la main au Shell et nous retrouvons notre familier :

2.WB1.3>

Il y a des programmeurs qui vont rugir et donner d'excellentes raisons techniques pour que leurs programmes soient "mal élevés". A ceci j'oppose une réponse double bien que simple :
  • Je me fous des raisons techniques, ce qui m'importe en tant qu'utilisateur, c'est le résultat.
  • Il y a des gens qui arrivent à écrire des programmes "bien élevés".
Pour les programmes mal élevés, nous utiliserons la commande "Run", ou une des commandes "Runback" ou "Arun" du domaine public, mais ceci viendra en son temps. Pour le moment, créons donc un fichier script avec ce que nous trouvons dans notre répertoire C:.

Créons un fichier script

Pour créer un tel fichier, que nous appellerons par exemple "Toto", juste pour faire original, nous envoyons :

2.WB1.3> ed Toto

Une fenêtre s'ouvre, intitulée "Ed 1.14" (ou une autre version le cas échéant), et au bas de laquelle nous lisons en rouge : "Creating new file".

S'il avait existé dans le répertoire racine de notre disquette WB1.3 un fichier nommé "Toto", son contenu aurait été affiché, à moins qu'il ne s'agisse d'un fichier binaire, auquel cas la fenêtre d'Ed se serait refermée immédiatement, en laissant le message : "File contains binary".

Bon, dans le haut de notre fenêtre d'Ed, tapons :

echo "Bonjour, voici des informations sur le système"
avail
info
echo "Au revoir"

Après quoi pressons la touche "Esc", il apparaît un astérisque dans le bas de la fenêtre, tapons "x", ce qui donne à Ed l'ordre d'écrire dans le fichier "Toto" ce que nous venons de taper, referme la fenêtre d'Ed et rend la main au CLI.

Vérification

Pour vérifier l'existence de notre fichier "Toto", tapons :

2.WB1.3> list toto
toto    87 ----rwed Today 15:37:22
  • Remarquez l'indifférence d'AmigaDOS aux majuscules et minuscules.
  • Nous sommes en présence d'un fichier nommé "toto", d'une longueur de 87 "mots", né aujourd'hui à l'heure indiquée.
  • Les lettres "rwed" signifient : r (read/lire, autorisé en lecture), w (write/écrire, autorisé en écriture), e (executable), d (delete/détruire, effaçable par la commande "delete").
Faites l'exercice, en utilisant la commande "Protect", de rendre Toto inaccessible à la lecture, non modifiable, ou impossible à effacer. Il suffit de taper "Protect" suivi des lettres convenables, vous pouvez en vérifier l'effet grâce à "List".

Quand vous avez fini, remettez Toto dans son état initial en tapant :

2.WB1.3> protect toto rwed

A présent nous allons faire fonctionner ce fichier, grâce à la commande "Execute". Mais tout d'abord, je vous demande de faire soit :

2.WB1.3> rename c:execute c:x

Soit :

2.WB1.3> alias x execute

Ceci permettra de taper "x" plutôt qu'execute qui est trop fatigant à mon goût.

Toujours une copie !

Remarques :
  • J'espère que vous travaillez sur une copie de votre disquette Workbench (vous n'êtes pas fou !).
  • Pour y faire de la place, virez donc Notepad de votre tiroir "System" (on l'a déjà dit, mais il faut parfois insister...).
  • Le premier qui me dira pourquoi dans le cas présent rename vaut mieux qu'alias aura un Yop fraise.
Celui qui me dira qu'en fait alias vaut quand même mieux que rename à condition de le mettre au bon endroit, est en avance de trois chapitres et à droit à un second Yop fraise.

Ceci fait, tapons :

2.WB1.3> x toto

...et le système, après une formule de politesse, nous donne de l'information sur la mémoire disponible, sur la place disponible sur la disquette et sur les gestionnaires activés, et finalement nous resalue aimablement.

fichiers script

Bien, me direz-vous, mais j'aurais obtenu la même chose bien plus vite en tapant directement les commandes en question. C'est évident, mais un programme n'est-il pas autre chose qu'une suite d'instructions que l'on peut faire se répéter à volonté par une seule commande de lancement ?

Script = Programme

Les fichiers script ne sont autres que de petits programmes constitués de commandes qui s'exécutent en série. L'exemple type en est la fameuse startup-sequence qui, au démarrage du système, le met en état d'être utilisé plus ou moins convivialement selon ce qu'elle contient et ce qu'elle met en action. Ce n'est pas fini ! Faisons :

2.WB1.3> cd libs
2.WB1.3:libs> x toto
EXECUTE: can't open toto

"Execute" n'a pas trouvé "Toto" dans le répertoire courant. Essayons en donnant au système le "chemin" complet (path) :

2.WB1.3:libs> x wb1.3:toto

Ou :

2.WB1.3:libs> x /toto

Ou :

2.WB1.3:libs> x :toto

Ou :

2.WB1.3:libs> x df0:toto

Ou enfin :

2.WB1.3:libs> x sys:toto

Et tout cà marche.

La répétition est l'âme de l'enseignement. Si vous ne voyez pas précisément pourquoi toutes ces syntaxes sont équivalentes, allez relire les articles suivants : Se déplacer dans les répertoires d'AmigaDOS avec le CLI et Les fichiers, unités et assignations sur AmigaOS 1.x. Si vous l'avez vu sans hésiter, vous avez de nouveau droit à un Yop fraise. A la fin de l'article, vous serez malade comme un chien, à moins que par chance vous n'aimiez pas le Yop fraise.

De plus en plus fort

Faisons :

2.WB1.3/libs> cd /
2.WB1.3> copy TOTO s:
2.WB1.3> delete TOTO
2.WB1.3> cd libs
2.WB 1.3> x toto

...et çà marche.

Un fichier de commandes placé dans le répertoire S: peut être appelé de partout par la commande Execute.

Et pour couronner le tout :

2.WB1.3> cd s:
2.WB1.3:s> protect toto srwed

Ou :

2.WB1.3:s> protect toto +s

Ou encore :

2.WB1.3:s> protect toto s add
2.WB1.3:s>list toto
toto    87 -s-rwed Today 16:25:30

Nous avons ajouté au fichier "Toto" l'attribut "s" qui lui donne une qualification complète de fichier script.

Faisons :

2.WB1.3:s> cd /libs
2.WB1.3:libs> toto

...et Toto s'exécute devant nos yeux qui devraient raisonnablement en être éblouis.

Un fichier de commandes, muni de l'attribut "s" et situé dans le répertoire S: est exécutable de partout, rien qu'en tapant son nom. En d'autres termes, il jouit des mêmes propriétés qu'une commande du répertoire C:.


[Retour en haut] / [Retour aux articles] [Article suivant]