# ##### # # # # #### # # # # # # # # # # ##### #### ###### ####### # # # # # # # # # # # ####### #### # # la vie l'univers et le reste, surtout le reste. 1) Details Administratifs : - Vous pouvez utiliser l'ensemble de la librairie standard. (les libs gnus ne sont pas standards) - Le projet devra se trouver (un et un seul par groupe) dans ${HOME}/rendus/c/proj/42sh/ - tout ce dont vous avez besoin doit se trouver dans le repertoire de rendu ou des sous repertoire. (rien ailleur meme avec les droits et des path absolut). - les questions sont a poser sur epitech.cours.c-unix.42sh les reponses de Nicolas Sadirac et Vincent Lecoq (seulement) seront considerees comme officielles. - L'ensemble du groupe devra etre present a la soutenance. - Vous pouvez (c'est meme plutot une bonne idee) travailler a plusieur groupes et confronter vos resultats. Par contre chaque groupe doit avoir une implementation qui lui est propre. - Vous pouvez vous repartir les points comme vous le voulez; mais cette repatition doit etre donnee au debut de la soutenance et avoir l'accord de tous. - il doit y avoir un fichier auteur avec un login (et que ca) par ligne. - chaque membre du groupe doit pouvoir expliquer le fonctionement general et le structures de l'ensemble, les structures utiliser et ce que fait chaque parties. Il doit aussi etre capable de montrer ce qu'il a fait lui meme et pouvoir le modifier ou le refaire a la soutenance. - Vous pouvez exclure des personnes du groupe jusqu'a 2 mois du rendu apres c'est plus possible. Il faut pour ca que la majorite du groupe soit d'accord. - Vous n'etes pas oblige d'avoir un chef de groupe mais on vous le conseil fortement. 2) Description du projet: - Il s'agit d'ecrire un SHELL. - Il se decompose en 2 parties (decritent plus avant): - Une partie obligatoire qui est a faire absolument note sur 8 points - Une partie optionelle qui ne peut etre faite que si la partie obligatoire marche completement. - la stabilite et l'utisabilite de l'ensemble sera largement prise en compte. Il serait souhaitable d'etre conforme aux usages et habitudes. 3) Partie obligatoire : Cette partie doit ABSOLUMENT MARCHER COMPLETEMENT. Et etre PARFAITEMENT STABLE avant que vous fassiez quoi que se soit d'autre, sinon ce sera 0. - Une acquisition de ligne minimale : - affichage d'un prompt (plus ou moins elabore) - recuperation de la ligne tape (get_next_line(0) devrait suffir) - Execution des commandes avec leur parametre (ex: $ls -l / ) - gestion correct des espaces et TABs - gestion du PATH (pas forcement de systeme de cash) - gestion des erreur et valeur de retour ex: $./str_maxlenoxc "ddd" "dd" "who" segmentation fault (core dumped) $ - les redirections : ex: $> /tmp/z -l - < > >> - les pipes - builtins: - cd (avec cd seul et cd -) - echo - exit - les separateurs : - ; - && - || ex: $cd /tmp;ls -l > /tmp/xx < /dev/null |echo * ;sleep 100& who;ls || who && pwd ; echo test 4) Partie optionelle : C'est sur cette partie que vous gagnerez (normalement) la majorite des points. Elle est globalement libre. Vous pouvez faire ce que vous voulez. Mais la coerrance de l'ensmble sera prise en compte. Encore une fois la stabilite sera beaucoup plus important que la quantite. Ne mettez pas une option qui pause de probleme au reste et surtout a la partie obligatoire. Pensez surtout a l'utilisabilite. - Liste d'options souhaitables: - les inhibiteurs (" ' \ ) ex: $ls "who|'" '"'"slt\"" - le globing * ? [ ] { } ex: $echo {a*[^c],b??.*[a-z]}/b*.{c,h} - le background ex: $sleep 100 & - les ` ex: $kill -9 `ps ax | grep netscape | awk '{print $1}'` - les () ex: $(cut -d\ -f2 .note | tr '\n' +;echo 0)| bc -l - les variables (local et d'env). ex: $set a=val;echo $a;ls $a;$a - variables speciales : term,precmd,cwdcmd,cwd,ignoreof ... - history ex: $history - avec ! ex: $!ls ex: $!12 ex: $!-4 - avec ! et modificateur ex: $!ls:s/.c/.h - linker avec l'edition de ligne - alias - edition de ligne: - multi ligne - avec rebinding dynamique - completion dynamique (fichier, commande, contextuel ....) - job control (tres tres aprecie) - scripting (tres long) 4) conseil. Formez un groupe solide: verifier que vous pouvez vraiment travailler ensemble (heurs, temps, caracteres). Travaillez vraiment en groupe (ensemble et en discutant). Passez beacoup de temps a analyser les choses a tous les niveaux. Verifiez que vous avez bien compris et que les autres membres de votre groupe ont compris la meme chose. Parlez en avec d'autres groupes. Ne codez rien avant que tout soit clair. Ne codez rien avoir d'avoir tout vos minishells qui marchent completement pour tout les membres du groupe. Je vous conseil meme de les refaire completement en groupe histoire de voir comment vous codez ensemble. Faites des senarios complets de fonctionnement de votre shell. Faites vous des jeux de test pour tous ce que vous comptez coder. cherchez tous les cas de figures (on les trouvera a la soutenance). confrontez vos listes de cas avec les autres groupes. Faites une liste claire des options que vous voulez faire en separant bien les etapes. Faites un plan general sur papier avant d'ecrire la premiere ligne. Quand vous aurez commerce a ecrire testez tout en meusure. N'esitez pas a effacer des parties qui vous semblent louches. Ne faites rien que vous ne compreniez completement. Si vous developpez en morceaux (ce qui a mon avis n'est pas une bonne chose au debut, vous devriez coder completement ensemble la partie obligatoire et la tester ensemble) assemblez tres souvent (1 a 2 fois par sem) et codez a cote les un des autres. Quand ca marchera, faites le tester par d'autres groupes. Puis quand ca marchera . Faites le tester a un tek2 ou tek3. Quand ca marchera. Faites le tester a un astek. Quand ca marchera faites le tester a Ares. Quand ca marchera (si ca arrive) faites le tester a flop. Il ne devrait pas y avoir de suite :-)