Obligement - L'Amiga au maximum

Vendredi 29 mars 2024 - 15:54  

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 : ARP et Shell ASH - Présentation, installation et utilisation
(Article écrit par Pierre Ardichvili et extrait d'A-News (Amiga News) - mars 1990)


Nous avons déjà parlé plusieurs fois de la bibliothèque ARP et elle est connue de beaucoup de monde. On peut en trouver les fichiers .ZOO sur SGT.FLAM (16-1-39 55 84 59), sur l'une des disquettes qui accompagnent l'ouvrage " Comprendre Et Bien Utiliser Son Amiga" de chez Titus, ou encore sur aminet.net/misc/antiq/ARP_13.lha.

Intérêts

La bibliothèque ARP a trois intérêts majeurs :
  • Elle permet de substituer aux commandes du répertoire C: des commandes de même nom, d'un haut niveau de compatibilité avec les commandes standard d'AmigaDOS, tout en étant plus puissantes, plus souples et moins encombrantes.
  • Elle permet de substituer le gestionnaire ASH au gestionnaire Shell-Seg de l'AmigaShell.
  • En coopération avec les gestionnaires CNC: et PIP: de ConMan, elle permet l'utilisation de vrais pipes.
Documentation et installation

Tout d'abord, la documentation comporte quatre parties, une introduction aux concepts de la bibliothèque ARP, le manuel du gestionnaire ASH, la documentation détaillée des commandes ARP, et une documentation plus approfondie à l'usage des programmeurs. Nous partirons, pour ce cas et les suivants, de la disquette standard Workbench 1.3.

Remarques préliminaires

1. Ouverture des fenêtres. Il faut garder présent à l'esprit que, pour ouvrir une fenêtre Shell, il faut trois choses : un gestionnaire de Shell résident en mémoire (Shell-Seg dans le cas d'AmigaShell, ASH dans le cas présent) ou une bibliothèque spécifique, une unité logique gestionnaire de console (CON: est le gestionnaire par défaut, qui n'a pas besoin d'être activé ; NEWCON: est le gestionnaire associé à l'AmigaShell, on l'active par "Mount NEWCON:" ; CNC: dont nous parlerons plus loin est le gestionnaire de ConMan, qui remplacera avantageusement NEWCON: et qui s'active par "Mount CNC:") et une commande. La commande d'ouverture des fenêtres AShell (qui correspond à NewShell) charge résident en mémoire le gestionnaire ASH à la première invocation ; il n'y a donc pas besoin d'utiliser la commande "Resident".

2. Commandes. Bien que le Shell ASH puisse fonctionner avec les commandes Commodore, il serait dommage de ne pas utiliser les commandes ARP, plus performantes et moins encombrantes. Les commandes de l'AmigaShell qui n'ont pas d'équivalent ARP seront conservées sans inconvénient.

Processus d'installation

Pour installer ASH et les commandes ARP, ainsi que pour créer les gestionnaires PIP: et CNC:, reportez-vous à la documentation ou à cet article. Il est sans doute utile de donner quelques indications au sujet des fichiers de commandes (scripts) à créer dans S :

Dans startup-sequence

setpatch
failat 25
sys:system/setmap f
mount cnc:
arun ashell cnc:0/0/640/100/AShell from s:ashell-boot
endcli

La fenêtre qui s'ouvre lors du processus de démarrage est toujours une fenêtre CLI. Pour pouvoir la refermer, nous ouvrons une fenêtre AShell en arrière-plan par ARun (grossièrement équivalente à "RUN >NIL:").

Dans ashell-startup

alias ns ashell cnc:0/0/640/100/AShell from s:ashell-startup
alias es endcli
prompt "%N %S>"
path sys: s: ram: sys:utilities sys:system add
cd sys:

Ceci vous permettra d'ouvrir une nouvelle fenêtre AShell, avec tous ses attributs en tapant "NS" et de la refermer par "ES". Vous pouvez bien évidemment ajouter d'autres alias et modifier l'invite de commande.

Dans ashell-boot

failat 25
alias as ashell cnc:0/0/640/100/Ashell from s:ashell-startup
alias es endshell
ares assign mount dir cd makedir list path
mount pip: aux: speak:
makedir ram:t ram:env ram:clipboards
assign T: ram:t ENV: ram:env CLIPS: ram:clipboards
path sys: s: sys:system sys:utilities ram: add
setclock opt load
cd sys:
loadwb

...plus toutes autres choses que vous souhaitez faire au cours de votre séquence de démarrage.

Cette séquence demande quelques explications :
  • On retrouve dans cette séquence le contenu de ashell-startup, ce qui est normal car pour la première fenêtre AShell lancée par la startup-sequence, ashell-boot joue le rôle de ashell-startup.
  • "cd sys:" sert simplement à activer l'invite de commande. En effet, seule la commande CD modifie l'invite de commande en fonction de sa définition par la commande "Prompt".
  • "loadwb" à moins d'avoir PopCLI ou quelque chose d'équivalent, chargez toujours un Workbench, car si par distraction vous fermez votre dernière fenêtre AShell, il ne reste qu'à redémarrer, ce qui est fort dommage s'il y avait en RAM: des choses précieuses.
Rendons à César ce qui est à César : personnellement, je trouve plus convivial le système de l'AmigaShell où la commande NewShell active automatiquement le fichier Shell-Startup qui définit la fenêtre qui va s'ouvrir, tout en permettant par l'option "From" d'utiliser un autre fichier de définition.

Encore une remarque : si dans la première startup-sequence vous lancez le programme ConMan, il n'est plus nécessaire par la suite de spécifier CNC: comme gestionnaire de console. On peut soit ne rien mettre du tout, soit spécifier CON:. Notons encore que ConMan vous permet de définir des fenêtres Shell dotées de caractéristiques diverses : fenêtre sans bordure, fenêtre "backdrop" (s'ouvrant en arrière-plan), munie ou non de ses gadgets. Sur une disquette ainsi aménagée il reste 182 blocs.

Compatibilité avec l'AmigaShell

Tout d'abord, les commandes ARP ont été conçues pour être aussi proches que possible, dans leur syntaxe, de celles d'AmigaDOS, vous ne serez donc pas dépaysés.

Attention : si vous voulez redémarrer à partir de RAD:, il faut lorsque vous créez le RAD: utiliser la commande "Mount" d'origine et non la commande ARP.

Par ailleurs, si pour une raison quelconque vous désirez conserver des éléments de l'AmigaShell, comme le gestionnaire NEWCON: ou la commande NewShell, par exemple, la commande AShell vous donnera le meilleur Shell possible : elle essaiera d'utiliser ASH, à défaut elle utilisera Shell-Seg si ce dernier est résident selon que vous aurez fait "mount NEWCON:" ou "mount CNC:", AShell utilisera le gestionnaire de console disponible, avec ses attributs. Si vous n'avez pas fait "mount CNC:" et "mount PIP:", par exemple, vous n'aurez pas à votre disposition le "Pipe" convivial dont nous parlerons plus loin, mais vous pourrez utiliser le "Pipe" de l'AmigaShell.

Il y a donc un peu de travail d'ajustement au niveau des séquences de démarrage selon ce que l'on veut obtenir.

Les commandes

Les commandes ARP fonctionnent avec le caractère générique "*" qui est un standard de l'industrie, mais elles acceptent aussi les caractères "#" et "?" de Commodore. De plus, la plupart des commandes ARP acceptent ces caractères, ce qui n'est pas le cas pour de nombreuses commandes d'origine.

Notre test classique : les syntaxes.

rename *.m *.c

Ou

rename #?.m #?.c

...marchent toutes deux.

En outre, par exemple :

list *.[ci]

...donne la liste des fichiers du répertoire courant dont le suffixe est "c" ou "i", et...

list ~*a

...donne la liste des fichiers dont le nom ne se termine pas par "a".

Il y a évidemment possibilité de conflit entre l'utilisation du caractère "*" comme caractère générique par ARP et son utilisation comme caractère d'échappement (escape) par AmigaDOS. La commande "Set" de ARP, qui sert à définir les variables d'environnement, possède une option "Escape" qui permet de définir un autre caractère d'échappement.

Les commandes ARP offrent beaucoup de possibilités additionnelles par rapport à leurs homologues Commodore ; il n'est pas question de les citer toutes. A signaler la commande ARun, que nous avons utilisée dans la startup-sequence ci-dessus. Elle est destinée à lancer un programme en arrière-plan, sans bloquer la fenêtre Shell. Elle remplit donc la même fonction que "Run >NIL:" de l'AmigaShell mais avec des possibilités supplémentaires ; l'exemple donné dans la documentation est :

ARun Funckeys NOIO STACKSIZE 2000 PRI -5

Pour faire la même chose avec AmigaShell dans lequel vous auriez un stack mis à 10000, il faudrait la série de commandes suivantes :

stack 2000
changetaskpri -5
run < NIL: >NIL: Funckeys
changetaskpri 0
stack 10000

A signaler aussi la commande "Move", qui est une commande "Rename" mais qui permet de déplacer des fichiers d'une unité logique à l'autre, exemple :

move dh0:compil/echecs.* dh1:jeux

Ou encore la commande "Search" qui accepte des caractères génériques tant dans la désignation des fichiers dans lesquels la recherche doit se faire, que dans la définition de la chaîne de caractères à retrouver. De plus, "Search" met cette dernière définition dans une variable d'environnement nommée "Search;" lors des invocations suivantes de "Search", c'est cette définition qui sera utilisée par défaut. Ceci est très pratique lorsqu'on a souvent à faire la même recherche.

Tout n'est pas parfait ; en cherchant bien, j'ai trouvé que la commande "Info" doit, d'après la documentation, accepter les deux syntaxes :

info <nom d'unité logique>

Et

info <nom de volume>

Cette deuxième syntaxe ne marche pas plus que dans l'AmigaShell. Par contre, la place mémoire indiquée pour les disques est la mémoire disponible formatée ; les chiffres donnés sont donc inférieurs à ceux que donne "Info" d'AmigaShell, mais plus réalistes.

Autre exemple d'amélioration de détail en apparence séduisante mais non sans piège : on peut utiliser les caractères génériques dans la spécification d'un chemin lors de l'utilisation de la commande CD :

CD b*/a*/p*/n*

...est équivalent à :

CD basic/aero/profils/naca009

C'est super pratique, avec tout de même une restriction : la commande choisit le premier répertoire dont le nom commence par "b" et dans celui-ci le premier sous-répertoire commençant par "a", etc. Bon, mais qu'entend-on par "premier" ? Pour m'en faire une idée, j'ai créé sur une partition appelée "Store:" de mon disque dur un répertoire "agaga" dans lequel j'ai créé les sous-répertoires "abc", "aha", "amu", "beb", et j'ai tapé :

CD a*/a*

...et la commande m'a mis comme répertoire courant "Store:agaga/aha".

Cette logique paradoxale a son origine dans la manière dont AmigaDOS écrit les fichiers sur une disquette.

Les commandes ARP fournissent deux niveaux d'aide. En frappant "?" après le nom d'une commande AmigaShell, on obtient le "template", pas toujours évident à déchiffrer. Dans le cas d'une commande ARP, un deuxième "?" fait apparaître la syntaxe (usage).

La commande "Resident" de l'AmigaShell est remplacée par "Ares", qui a deux avantages :
  • Ares ne charge une commande en mémoire que la première fois qu'on appelle cette commande.
  • Ares surveille l'intégrité des commandes mises résidentes en mémoire ; au premier appel, la commande est chargée et exécutée ; au second, si la commande n'était pas "pure" et que donc son image binaire en mémoire s'est modifiée, Ares fait un test de somme de contrôle et vous en avertit par une fenêtre de requête avant de procéder à l'exécution, ce qui vous épargne potentiellement un krash.
Il y a encore, entre autres, deux commandes intéressantes : "Tackon" qui permet d'attacher le nom d'un fichier à celui d'un chemin, et "Basename" qui extrait le nom du fichier du chemin complet. L'utilisation de ces commandes avec la traduction des variables (voir plus bas) permet l'écriture de scripts particulièrement performants pour les actions de mise à jour d'ensembles importants de fichiers.

Pas plus que dans AmigaShell, il n'y a dans la bibliothèque ARP de commande permettant l'association d'une chaîne de caractères aux touches de fonction.

Modification des lignes de commandes et historique

Les possibilités offertes sont celles de l'AmigaShell, avec en plus le fait de pouvoir effacer un mot complet à gauche ou à droite par F7 et F8. Par contre, si vous ajoutez dans votre répertoire C: ConMan et sa commande "History", et si vous lancez ConMan dans votre séquence de démarrage, vous pourrez à tout moment sauver l'historique des commandes d'une session, et le rappeler. Vous pourrez d'ailleurs éditer ou créer un tel historique avec n'importe quel éditeur (mais pas avec un traitement de texte qui insère des caractères non affichables).

Amélioration de l'environnement de travail

Le "Pipe" fourni par l'unité PIP: en conjonction avec le gestionnaire CNC est un "vrai" pipe qui lance des tâches concourantes au lieu de faire appel à des fichiers temporaires. On peut faire :

list | sort | more

Autre exemple plus intéressant : on peut se faire une idée de l'abondance des commentaires des sources d'un programme. Prenons l'exemple du répertoire "AnalogJoystick" de la disquette Fish 247. Il contient deux sources Joydemo.c et Joydrive.c. Faisons :

search *.c /'* | type opt n | more

...et nous constatons que Joydemo.c a, sur 425 lignes, 85 lignes de commentaires, que nous pouvons d'ailleurs lire à l'aise avec More, et que Joydrive.c a 93 lignes de commentaires sur 349. Remarque : l'apostrophe devant le second astérisque est là pour le différencier d'un caractère générique.

Je mentionnerai encore que, sans avoir besoin de lancer ConMan, on dispose de l'iconification des fenêtres (bascule) ou de leur extension à tout l'écran (bascule également) par les touches F1 et F2.

Les fichiers de commandes

ASH soutient l'attribut "S" de l'AmigaShell, avec les avantages que cela procure. Comme nous l'avons déjà mentionné plus haut, sont internes à ASH, et donc d'accès rapide, les commandes les plus souvent utilisées dans les scripts, à savoir =, EndCLI, Alias, Run, Execute, Failat, Quit, Skip, EndSkip, Lab, If, Else, EndIf.

Ash permet de définir des variables locales (par opposition aux variables d'environnement) ; il exécute de plus des opérations dites en américain "variable expansion" et "command substitution". Je traduis ceci comme je peux : "traduction des variables" et "substitution des commandes".

On peut utiliser la traduction des variables dans les lignes de commande, dans les fichiers de commandes, dans les alias et dans la définition de l'invite de commande. Sous ASH, vous pouvez définir une variable comme ceci : unité=mètre.

Le caractère "=" est en fait une commande d'ASH.

Attention : pas d'espaces ! Et ne l'utilisez pas à la place de EQ dans une commande IF !

Les variables d'environnement du type AmigaShell restent accessibles par "SetEnv" et "GetEnv".

Vous pouvez aussi, dans une ligne de commande, obtenir la substitution du résultat d'une commande à son énoncé, voici un exemple qui illustre les deux concepts à la fois :

Les deux lignes :

nom=Say
echo "Le chemin du fichier $nom est $(which $Say)."

...donnent comme résultat :

Le chemin du fichier Say est Workbench1.3:Utilities/Say.

Il y a encore un petit bijou à trouver dans cette chasse au trésor, ce sont trois variables locales appelées "$", "?" et "?2". La première est équivalente au "$$" de l'AmigaShell et contient le numéro du Shell en cours. "?" donne le "return code" de la dernière commande exécutée et "?2" donne la réponse éventuelle du système, (result2) c'est-à-dire pour une commande, le code d'erreur. Exemple : soit le fichier script appelé "MD".

failat 25
makedir >nil: sys:c
echo > ram:rapport "Shell# $$ rc=$? res=$?2"

Faisons :

execute MD
type ram:rapport

Résultat :

Shell# 2 rc=20 res=203

...ce qui est normal puisque sys:c existe déjà.

Ceci permet donc, dans un script non interactif, d'obtenir des renseignements sur le fonctionnement d'une ou l'autre commande, en sauvant dans un fichier les valeurs des dites variables.

La documentation donne plusieurs exemples qui montrent bien la puissance de toutes ces possibilités utilisées dans des fichiers de commande.

Conclusion

Voilà quelque chose de nettement plus puissant et convivial que l'AmigaShell ; l'utilisateur n'est pas obligé de mémoriser de nouvelles commandes et leur syntaxe, vu l'effort réalisé en vue de la compatibilité avec l'AsnigaShell. On peut approcher les possibilités d'ASH et ARP d'une manière progressive, c'est un peu le Meccano, à ceci près qu'on ne "voit" pas physiquement toutes les pièces.

Il y a un peu de travail à faire au niveau des séquences de démarrage et de la liste de montage ; il est utile d'imprimer les éléments de configuration de votre système (startup-sequence, liste de montage, liste des gestionnaires (handlers) et bibliothèques) car on ne se souvient pas toujours de ce qu'on a fait et on se demande parfois pourquoi le système fait autre chose que ce que l'on attend.

Enfin, ce n'est pas un investissement coûteux puisqu'il s'agit de programmes du domaine public; les auteurs de ARP ne demandent aucune rétribution, quant à William Hawes, il reçoit avec plaisir 15 dollars pour ConMan, à votre jugement...


[Retour en haut] / [Retour aux articles]