Rapport de Shell

PROJET SYSTEME

SHELL

Sommaire

1.     Introduction        2

2.        Fonctionnalités du shell        2

2.1. Signaux : « signal_manager.c »        2

2.2. Présentation : « presentation.c »        2

2.3. Exécution : « executor.c », « syntaxe_prompt.y », « analyse_prompt.lex »        3

2.4. Pipe : « executor.c », « pile_exec.c »        3

2.5. Exécution séquentielle : « executor.c »        3

2.6. Alias : « alias.c »        3

2.7. Variables et variables d’environnement : « variable.c »        3

2.8. Redirections : « redirection.c »        4

2.9. Variable PS1 : « prompt.c »        4

2.10. Help : « presentation.c »        4

2.11. Nice : « pile_exec.c »        5

2.12. Gestion des mauvaises exécutions : « executor.c »        5

2.13. WildCard : « executor.c », « pile_exec.c »        5

2.14. Complétion des commandes : « prompt.c »        5

2.15. Job control : « executor.c », « internal.c »        5

3.        Programmation du shell        6

3.1. Interpréteur de commandes        6

3.1.1. Readline        6

3.1.2. LEX        6

3.1.3. YACC        6

3.2. Exécuteurs de commandes        6

3.2.1. cd : « internal.c »        6

3.2.2. alias : « syntaxe_prompt.y »        6

3.2.3. unalias : « syntaxe_prompt.y »        6

3.2.4. export : « syntaxe_prompt.y »        7

3.2.5. bg : « internal.c »        7

4.        Conclusion        7

5.        Annexe : cahier de test        8

1. Introduction

Ce projet de système a pour but de réaliser un shell tel que le bash avec ses principales fonctionnalités. Pour cela nous avons considéré 2 grandes parties :

• interpréteur de commandes avec readline, LEX et YACC,
• mise en oeuvre des fonctions liées à ces commandes.

Nous étions 4 pour réaliser ce projet, nous nous sommes organisés en 2 groupes de 2. Le premier a implémenté l’interpréteur de commandes pendant que le second se chargeait des fonctions liées à ces commandes. Afin que les deux parties puissent être bien compatibles, François s’est chargé de leurs interconnexions.

De plus chacun a apporté sa contribution et ses idées au service du groupe. Et chacun s’est aidé pour implémenter certaines fonctions.

Voyons à présent ce dont est capable notre shell et comment avons nous fait pour le mettre en oeuvre.

1. Fonctionnalités du shell

Pour programmer notre shell nous avons, tout d’abord, respecté certaines conventions :

• syntaxe des noms de variable (<type>_nom_variable) s’il s’agit d’une variable globale elle commencera par une Majuscule,
• syntaxe des noms de fonction (<type de retour>_nom_fonction),
• syntaxe des messages d’erreurs, affichage du nom de la fonction où s’est produite l’erreur ainsi que le message correspondant.

Au cours de la mise en œuvre du shell, nous avons implémenté pour l’instant trois versions et nous en avons prévu une quatrième.

Première version

2.1. Signaux : « signal_manager.c »

Dans un premier temps nous nous sommes attachés à la gestion des signaux, ce point nous semblait le plus important.

Pour cela, nous avons protégés les signaux « SIG_QUIT » et « SIG_INT ». En effet, le shell ne doit pas sortir lorsque l’on tape « Ctrl-C » ou « Ctrl-Alt-BkSp ».

En revanche les processus qui reçoivent ces signaux doivent s'arrêter.

De son côté, le signal « SIG_STP » sert pour la gestion du « job-control », il est envoyé lorsque l'utilisateur tape « Ctrl-Z ».

2.2. Présentation : « presentation.c »

Lors du lancement du programme principal de notre shell (« ./shell »), on peut voir s’afficher le nom de l’utilisateur, le temps de connexion sur le « tty » ainsi que le « pid » du shell.

Concernant le temps de connexion de l'utilisateur sur le « tty », nous nous sommes servis des primitives de gestion des fichiers « utmp » (« /var/run/utmp »).

2.3. Exécution : « executor.c », « syntaxe_prompt.y », « analyse_prompt.lex »

Afin d’exécuter la commande tapée par l’utilisateur, nous évaluons, au préalable, cette dernière avec leurs arguments, y compris les options.

Pour cela on gère une pile d'exécution contenant les commandes et une liste d'arguments (« pile_exec.c » et « pile_exec.h »).

Toutes les informations sont récupérées depuis une file gérée par LEX et YACC (« file.c » et « file.h »).

Enfin les commandes sont dépilées et interprétées par la fonction « i_eval » (« executor.c »).

2.4. Pipe : « executor.c », « pile_exec.c »

Nous avons géré le pipe de façon récursive afin d'en exécuter plusieurs sur la même ligne de commande.

Lorsque LEX détecte le caractère « | », il positionne un flag sur la dernière commande ajoutée dans la pile. Au moment de l'évaluation nous vérifions la présence de ce flag afin de dupliquer les descripteurs.

...