Obligement - L'Amiga au maximum

Vendredi 29 mars 2024 - 09:35  

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

 


Test d'AUSH (Amiga Ultimate Shell)
(Article écrit par Pierre Ardichvili et extrait d'Amiga News - juillet 1992)


Il faut croire que l'AmigaShell, descendant d'un CLI austère, ne répond pas encore à toutes les attentes des utilisateurs, car la floraison des Shell de remplacement continue. Après la grande époque de Shell (le premier Shell de Matt Dillon), ASH (le Shell ARP), WShell, puis des Shell de style Unix, les plus célèbres étant CSH et SKSH, on a encore vu apparaître, entre autres, Line, PolySilicon, ZShell et TShell.

Récemment, William Hawes a sorti une nouvelle version de WShell, CSH a encore été amélioré et Denis Gounelle vient de nous sortir AUSH, objet du présent article. Le nom est à lui-même tout un programme : "Amiga Ultimate SHell". Rien que ça ! On verra...

L'objectif recherché par Denis était de réunir dans un même Shell la plupart des possibilités offertes par différents Shell, et que l'on ne trouve pas rassemblées dans un seul produit, tout en conservant une grande simplicité d'emploi et d'installation. WShell reste probablement la référence dans le domaine des Shell non typés Unix ; ceux qui au bureau ou à la fac bossent sur Unix aiment souvent retrouver un environnement similaire sur leur Amiga. La référence traditionnelle en matière de Shell plus typés Unix est CSH. Comment se place AUSH entre ces deux ténors ?

Premier contact avec AUSH

Côté installation, c'est réussi : il suffit de copier le programme AUSH et la commande "NEWAUSH" dans c:, environ 30 ko (très raisonnable), d'écrire si on le souhaite un fichier de configuration à mettre dans s: (quelques centaines d'octets) ; l'inévitable arp.library est plus que probablement déjà dans votre répertoire Libs:. Par comparaison, WShell pèse un peu plus lourd (environ 55 ko au total pour la version 2.0), et tout cela n'est rien à côté des 92 ko de CSH. Ceci sans tenir compte de la bibliothèque ARP (dont seul WShell n'a pas besoin).

Côté utilisation, c'est également très bien, AUSH se lance aussi bien depuis son icône que depuis une fenêtre AmigaShell ou WShell (ce sont les deux Shell résidents sur ma bécane - l'AmigaShell pour avoir la référence "standard" et WShell pour le plaisir - j'avoue n'avoir pas eu le courage de réinstaller une demi-douzaine d'autres Shell pour déceler d'éventuelles incompatibilités d'humeur) et fait bon ménage avec les deux. On peut lancer AUSH dans la fenêtre en cours, ou en ouvrir une nouvelle par la commande "NEWAUSH", cette fenêtre étant bien évidemment paramétrable. Au démarrage, AUSH cherche et exécute le fichier .aushrc qui contiendra entre autres les initialisations des variables de configuration.

AUSH
Figure 1

Contrairement à ce que font d'habitude les utilisateurs d'Unix quand ils écrivent un Shell pour l'Amiga, Denis a écrit le sien pour ne pas dérouter l'utilisateur de l'Amiga. Il n'a donc pas systématiquement choisi pour la trentaine de commandes internes des appellations typiques d'Unix. Tout au plus en retrouve-t-on des traces comme "Source" au lieu de "Execute" pour lancer un script, ou la dénomination typique ".aushrc" pour le fichier de configuration. Incidemment, AUSH ne reconnaît pas la commande "Execute" d'AmigaDOS, et ne reconnaît pas l'attribut "s" des scripts. Il faut donc impérativement les lancer par "Source". Les programmes ARexx se lancent sans problèmes par RX.

AUSH accepte les commandes AmigaShell 1.3 et 2.04, ainsi qu'en principe les commandes ARP. Celles-ci deviennent d'autant moins nécessaires que les commandes Commodore, inspirées des commandes ARP, ont considérablement maigri, et que AUSH autorise avec les commandes Commodore l'utilisation des métacaractères "#?" et "*" indifféremment, ce qui donne le maximum de souplesse. Il y a toutefois dans ARP la commande "Move" qui n'existe pas chez Commodore, et la commande "Search" qui reste un peu plus puissante que son homologue d'origine. J'ai toutefois buté sur le fait que sous AUSH les commandes ARP comme "Copy", "List", "Move" et "Rename" refusaient apparemment de fonctionner lorsque l'argument contient un métacaractère. En fait, AUSH se charge de l'expansion du métacaractère, et les commandes ARP aussi, d'où conflit. Il suffit alors de mettre le métacaractère entre apostrophes, par exemple :

move '*' toto

AUSH traite alors "*" comme une chaîne, sans l'interpréter, la commande ARP fait l'expansion et tout se passe bien. Ce conflit d'expansion des métacaractères existe aussi avec les commandes Commodore comme "List", qui effectuent elles-mêmes des expansions de métacaractères.

Ceci illustre le fait que la documentation, qui s'intitule sans complexe "manuel de référence (10 pages), est bien un document de référence et non un guide de l'utilisateur. En effet, comme on a pu le voir ci-dessus, le comportement à première vue surprenant des commandes ARP est néanmoins parfaitement logique en fonction de ce qui est écrit dans la doc, à savoir qu'une chaîne entre apostrophes n'est pas interprétée. Ou vous avez bien l'esprit informatique et vous trouvez cela tout seul comme un grand, ou vous avez comme moi un cerveau lent (souriez SVP, merci) qui ne comprend qu'à coup d'exemples et cela vous coûte un courrier ou un coup de téléphone à l'auteur (très aimable au demeurant, mais n'abusez pas !), ou vous concluez à tort que le truc est bogué. Cela dit, la doc est complète, claire et précise, en anglais et en français.

Au passage, je rappelle que la commande "Mount" de ARP est dangereuse ; déjà en 1.3, son utilisation pour monter un disque virtuel de type "VDK:" causait la disparition du contenu dudit VDK: lors d'un redémarrage à chaud (même avec l'utilisation de "Setpatch R"). En 2.0, le fait d'utiliser la commande "Mount" de ARP m'a régulièrement causé le plantage de la commande NEWAUSH. Aucun problème avec la commande "Mount" de Commodore.

L'interprétation des lignes de commandes

Il serait difficile de présenter ici toutes les possibilités offertes sans reproduire le texte intégral de la documentation. Je vais plutôt m'attacher à relever certaines choses significatives. Mentionnons donc :

  • Une grande souplesse dans la possibilité d'accepter des caractères ou des chaînes de caractères, en les interprétant ou non.

  • L'écriture de plusieurs commandes par ligne (un bon point pour AUSH, car c'est un manque surprenant de WShell).

  • La possibilité d'actions en cascade :

    SET var 'cmci'

    ...donne à une variable la valeur de la première ligne produite en sortie par la commande entre guillemets. Exemple :

    SET toto 'type bidule'

    ...donne à la variable "toto" la valeur de la première ligne du fichier "bidule" c'est le "backquote", héritage d'Unix.

  • La possibilité de placer les redirections (">" ou "»" ou "<>") n'importe où dans la ligne de commande.

  • Le lancement de commandes en arrière-plan et/ou avec une priorité indiquée dans la ligne de commande. Exemple :

    LIST > toto &-5

    ...lance la commande "List" en arrière-plan, avec la priorité -5. AUSH a l'amabilité de vous avertir du lancement de la commande en arrière-plan, de plus, il vous donne une ligne d'information lors de la première exécution de commande qui suit la fin de l'exécution de la commande lancée en arrière-plan.

  • L'exécution de scripts avec passage d'arguments multiples, disponibles sous forme de variables intitulées $1, $2, etc.

  • Une gestion très complète de l'historique des commandes avec, entre autres, la particularité de rappeler une commande par un numéro. En effet, lors d'une session AUSH, chaque lancement de commande se voit attribuer un numéro d'ordre unique. Ceci est très commode pour rappeler rapidement une commande de l'historique (la commande "History" affiche l'historique avec les numéros).

  • Une édition très complète de la ligne de commandes avec, entre autres :
    • La possibilité de définir un ou plusieurs délimiteurs de mots, ce qui est très commode en conjonction avec les fonctions "mot précédent" et " mot suivant " (Shift-flèche gauche, Shift-flèche droite) ; ceci se fait en définissant une variable spéciale nommée "delim". Exemple :

      set var delim ":/"

      ...permettra de remonter dans le chemin d'un fichier en s'arrêtant à chaque niveau de la hiérarchie des sous-répertoires, y compris le répertoire racine.

    • Et surtout une fonction "name completion". Lors de la frappe d'une commande, le fait de frapper un "Tab" enclenche la recherche d'un nom de fichier, de sous-répertoire ou de variable, qui complète les caractères frappés.
  • La mise en ou hors-service de l'édition de la ligne de commandes selon le mode AUSH par l'affectation de la valeur "1" ou "0" à une variable spéciale appelée "lineedit". Ceci permet de passer instantanément à un autre gestionnaire de console. Par exemple, la séquence :

    set lineedit 0
    ConMan

    ...met hors-service l'éditeur de lignes de commandes d'AUSH, lance ConMan, ce qui confère à la session AUSH en cours les caractéristiques du gestionnaire CNC:, par exemple le dimensionnement de la fenêtre par F1 et F2, et la recherche d'une commande dans l'historique à partir de ses premiers caractères via les touches F5 et F6.

  • Les fonctions "PUSHD" et "POPD" analogues à celles de WShell.

  • Une "commande" Ctrl-V , ou ^V, dans laquelle le mot précédent dans la ligne de commande est considéré comme une variable et remplacé par la valeur de cette variable.

  • L'assignation d'une chaîne à une touche de fonction (de F1 à F10 et de Shift-F1 à Shift-F10) en attribuant une valeur à une variable $f1 à $f10 ou $F1 à $F10 respectivement. AUSH gère la fonction ConClip de l'AmigaShell 2.04. Encore une fois, ceci n'est pas exhaustif. On retrouve des choses similaires dans WShell et dans CSH, sous des formes parfois légèrement différentes.

    Les commandes

    Les commandes internes ont vu leur nombre limité à une trentaine et ne portent pas de noms barbares ; c'est très bien ainsi. Personnellement, je hais (et oui) le système des commandes internes. Cela me fait irrésistiblement penser au command.com du MS-DOS. Les commandes internes ne peuvent être modifiées qu'à chaque nouvelle version du logiciel. Le concept de répertoire C: de l'Amiga me semble bien plus souple. Je préfère de loin mettre certaines commandes résidentes via la séquence de démarrage, en fonction de mes besoins. Certains auteurs ont une philosophie complètement opposée, il y existe au moins un Shell qui comporte 100 commandes internes, et la doc de CSH mentionne comme un avantage que l'on peut se passer du répertoire C. Affaire de goût et d'habitude, sans doute.

    Contrairement à WShell qui gère ses propres commandes internes et celles d'AmigaDOS, AUSH n'a accès qu'à ses propres commandes internes. Par contre, on y trouve des choses qui en valent vraiment la peine comme une commande de boucle "FOR ... DONE" et une commande "IF... ELSE ... ENDIF" qui possèdent un mode interactif. Les variables spéciales prompt1, prompt2 et prompt3 vous permettent de définir des invites différentes, grâce auxquelles vous pourrez toujours savoir si vous êtes en mode normal, ou à l'intérieur d'une boucle interactive FOR ou IF. Pour mettre des scripts au point, c'est superbe. La figure 1 donne un exemple de ce mode interactif.

    Dans la construction "IF condition expression ELSE", etc., la condition revêt certains aspects intéressants, elle peut être entre autres :
    • d nom vrai si "nom" est un répertoire.
    • e nom vrai si "nom" existe.
    • f nom vrai si "nom" est un fichier.
    • s nom vrai si "nom" est un fichier non vide.
    Pour ces quatre éventualités, le fait de mettre la lettre-clé "d", "e", "f" ou "s" en majuscule fera tout simplement avorter la commande au cas où le volume n'est pas présent, a mal été orthographié, etc., sans faire apparaître la demande "Please insert volume ...".

    Enfin, une dizaine de commandes sont destinées aux manipulations sur les variables.

    Les variables

    Il y en a trois sortes : locales, globales et spéciales. Là, c'est à la fois une satisfaction et une petite déception. Satisfaction pour les utilisateurs travaillant encore sous 1.3, vis-à-vis de WShell qui n'a pas de variables locales propres. Il gère les variables locales d'AmigaDOS, quand il y en a, c'est-à-dire sous 2.04. Petite déception car dans AUSH, les variables dites globales devraient s'appeler locales, vu qu'elles ne sont valables qu'à l'intérieur d'une session AUSH. Les variables dites locales ne sont valables qu'à l'intérieur d'un script.

    Puis consolation car ce découplage entre les variables propres à la session AUSH et celles que contiennent les scripts est intéressant, surtout dans le cas de lancement de plusieurs instances d'un même script. Puis redéception car AUSH n'a pas accès aux variables d'environnement du système. L'auteur modifiera peut-être ceci par la suite, mais ce n'est pas prévu dans l'immédiat. Une variable d'AUSH peut être protégée contre toute affectation ultérieure d'une autre valeur par une commande "read only vars".

    Les variables spéciales

    Les variables spéciales servent à déterminer un certain nombre de paramètres de la session, on les utilisera par conséquent principalement dans le fichier ".aushrc". Elles concernent comme bien se doit le contenu de l'invite et de la barre de titre, le mode de fonctionnement de l'historique des commandes, et un certain nombre de caractéristiques de l'édition de la ligne de commande.

    Une remarquable variable "dircmd" détermine l'action qui sera déclenchée par la frappe du nom d'un répertoire. La définition suivante :

    alias dircmd 'cd'

    ...donnera lieu au "cd" implicite qui nous est maintenant familier grâce à WShell puis à l'AmigaShell. Mais on peut sophistiquer :

    alias dircmd 'cd [], list files quick'

    ...effectuera, à la frappe du nom de répertoire "toto" :

    cd toto list files quick

    Citons aussi la variable "trap" qui permet d'arrêter l'exécution d'un script ou d'une boucle "FOR ... done", par l'appui sur "Ctrl-C" ou "Ctrl-D", avec la possibilité de donner une instruction quant à la suite des événements après l'interruption.

    Imaginons que notre script ait créé un fichier "tempfile", nous pourrons demander que l'interruption ait pour effet la destruction de ce fichier temporaire et la sortie du script avec un code de retour 20 par exemple :

    set trap 'delete $tempfile, exit 20'

    Enfin, signalons une variable "language" (il n'y a pas de faute d'orthographe, la variable porte le nom anglais) à laquelle on affectera la valeur "english" ou "deutsch" pour que les messages sortent en anglais ou en allemand au lieu du français utilisé par défaut.

    Ces variables spéciales étant principalement destinées à être utilisées dans le fichier de démarrage ".aushrc", appelé et exécuté à chaque lancement de AUSH (exactement comme le fichier shell-startup de l'AmigaShell). Dans AUSH, ne sont pris en compte que les chemins et les alias définis dans le fichier ".aushrc" exécuté lors de l'ouverture de chaque session.

    En ce qui me concerne, je préférerais que certaines variables spéciales, ainsi que certains alias et certains chemins puissent être définis une fois pour toutes dans un fichier qui s'exécute lors du premier appel à AUSH. L'idée est de garantir qu'un certain nombre d'alias et de chemins soient définis en permanence et d'éviter l'exécution d'un long fichier à chaque ouverture d'un Shell. Par ailleurs, la définition des chemins aurait pu poser des problèmes sous 2.04, car la commande "Path" est interne à l'AmigaShell et AUSH n'y a donc pas accès. Il y a par conséquent une variable spéciale "Path" pour ce faire.

    De divers éléments (non-accès aux commandes internes ni aux variables d'environnement d'AmigaDOS, non-transmission des chemins ou des alias) se dégage une impression de caractère un peu "isolationniste" d'AUSH par rapport au système.

    Les expressions

    AUSH peut évaluer des expressions entières exprimées en notation polonaise inversée. En fait, la commande "Eval" met AUSH en mode d'évaluation des expressions logiques tapées sur chacune des lignes qui suit, et affiche le résultat de cette évaluation.

    Tout comme la commande "Eval" de l'AmigaShell, cette commande devant servir surtout à incrémenter ou décrémenter des variables, et à faire des opérations simples, elle ne travaille que sur des nombres entiers. Que le fait qu'il y a un opérateur de division (/) ne vous amène pas à faire des calculs arithmétiques comportant des divisions à l'intérieur d'autres calculs, les résultats ne seront pas toujours ce que vous attendez. L'exemple de la doc le montre bien : "echo { 34 3 / 4 + }" donne "15".

    Les souhaits

    J'aimerais bien voir arriver dans les prochaines versions de AUSH :
    • Une commande "NEWAUSH" avec une syntaxe :

      NEWAUSH [<fenêtre>][FROM<fichierconfig>]

      ...de manière à pouvoir, par des alias, commander l'ouverture de fenêtres de configurations différentes, par exemple de menus spécifiques grâce à ParM.

    • Une gestion des chemins un peu plus élaborée (voir le PathMan de WShell).
    • Un gadget de fermeture de la fenêtre.
    • L'accès aux variables d'environnement.
    • Une doc plus explicite en général, sur les conditions d'expansion des métacaractères en particulier, et surtout avec des exemples.
    Comment se place AUSH ?

    Il est rare qu'un seul programme fasse tout ce qu'on peut être amené à vouloir, faire à un moment ou à un autre. AUSH n'échappe pas à cette règle ; bien que ne possédant pas toutes les fonctions de WSHell par exemple, AUSH se paie le luxe d'en offrir d'autres que WSHell ne possède pas. La comparaison avec CSH est également difficile. CSH procède d'une philosophie assez particulière, héritière d'Emacs, des premières versions de DME, etc. La convivialité n'est pas ce qui est recherché en premier lieu, il y a beaucoup de choses à mémoriser, par contre, la puissance est énorme.

    Côté conception, je situerais pour ma part AUSH quelque part entre WShell, dont un des objectifs déclarés est la plus grande compatibilité possible avec l'AmigaShell (vous pouvez vous servir de WShell comme si vous étiez dans l'AmigaShell, puis apprendre les finesses progressivement), et CSH, le bonheur de ceux qui font de l'Unix la journée et de l'Amiga le soir, puissant mais un peu usine à gaz et demandant un sérieux apprentissage si on ne vient pas d'Unix. Côté puissance, c'est volontairement plus léger.

    Ce Shell recevra certainement encore des mises au point et des modifications en fonction des réactions des utilisateurs.

    Conclusion

    En bref, AUSH est un Shell de style Amiga dans lequel on trouve beaucoup de très bonnes choses. On l'installe en un clin d'oeil, et on s'en sert très facilement. Il y a quelques manques, à vous de juger.

    Est-ce le Shell "Ultime" que nous promettait son titre ? Cela dépendra de la quantité de travail que Denis Gounelle voudra bien encore y mettre et des encouragements qu'il recevra. C'est en tout cas un outil qui enrichira votre environnement de travail sur Amiga.

    Essayez AUSH, à travers ce produit, vous ferez la connaissance d'un auteur dynamique, et vous ne serez pas déçu. La panoplie des programmes de Denis Gounelle s'étend toujours. Pour l'instant, il nous prépare... mais ça, c'est une autre histoire.

    Nom : AUSH.
    Développeur : Denis Gounelle.
    Genre : Shell.
    Date : 1992.
    Configuration minimale : Amiga OCS, 68000, 512 ko de mémoire.
    Licence : partagiciel.
    Prix : 40 FF.


    [Retour en haut] / [Retour aux articles]