Discussion :

[nixmind]

Salut tout le monde.

je suis pas un as de la programmation, et en ce moment je suis sur un projet consistant a realiser un mini shell;

J'ai code mon mini shell, les commandes fonctionne parfaitement, et maintenennt je suis a la phase des builtins et signaux. Pour les builtins, je pense pouvoir les recoder, mais pour les signaux, je suis un peu bloque la.

En fait le man de signal ne m'aide pas beaucoup, je dois gerer les signaux comme dans le shell par defaut du system(je suis sous linux). j'aimerais donc que vous me donniez des astuces pour programmer la gestion des signaux, je ne suis pas autorise a utiliser des fonctions comme fflush(stdout), juste la commande signal dans mon code.

Je peux arriver a coder mes fonctions pour les signaux si vous m'edifiez un avec des astuces pratiques.

merci infiniment pour votre precieuse aide.

A bientot.

[matafan]

Tu veux faire quoi exactement avec les signaux ? Un shell ne fait rien de particulier avec les signaux. A part si tu essaies de coder le built-in "trap" ?

[nixmind]

Salut!

Je m'exprime peut etre mal.

En fait je veux que les signaux soient gerer dans mon shelle comme dans le shell par defaut. Si par exemple j'entre Ctrl+C au clavier, mon invite de commande doit se rafficher et non celle du shell par defaut Si j'appuie la touche de rappel d'une commande(fleches montantes et descendante du clavier) je dois revoir les commandes comme dans mon tcsh et dans mon bash. Des trucs des ce genre

je veux juste gerer un peu les signaux afin d'optimiser mon mini shell. L'idee que j'ai est par exemple de definir une fonction qui recupere le signal(handle_signal par exemple), et qui sera rappeler dans elle meme. Je ne sais pas si elle me pemettra de bien controler les signaux, et si oui , je voudrais un bout de code a titre d'exemple et un peu explique, qui me permettra de commencer, car j'arrive pas a bien scerner l'utilisation des signaux et je suis dans les delais pour rendre mon projet
Voila, maintenant si j'ai utilise peut etre les termes a tort, j'espere que ma problematique est plus precise
Merci de me donner une petite piste..

merci pour votre attention

[Obsidian]

Comment lances-tu ton shell actuellement ? Si tu le fais depuis un autre shell, il y a des chances pour que ce soit celui-ci qui intercepte les caractères spéciaux en premier.

[Sve@r]

En fait le man de signal ne m'aide pas beaucoup, je dois gerer les signaux comme dans le shell par defaut du system(je suis sous linux).

Salut

Le principe d'un signal/kill est le suivant
Tu codes une fonction destinée à être exécutée à réception d'un signal. Cette fonction peut faire ce que tu veux mais tu n'as pas le droit de la mettre autre chose que void et avec un paramètre de type int. Ce paramètre recevra le signal reçu
Exemple

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void myFunc(int sig)
{
    ... blablabla...
}

Ensuite, tu dois armer ton code pour qu'il soit redirigé sur la fonction dès qu'il reçoit un signal x. Ca se fait une seule fois par la fonction signal. Mais rien ne t'empêche de relier ta fonction à plusieurs signaux

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
signal(10, myFunc);
signal(11, myFunc);
signal(12, myFunc);

Ainsi, si ton programme reçoit un signal 10, 11 ou 12 (envoyé depuis l'extérieur via kill) il sera automatiquement redirigé sur myFunc puis, une fois myFunc terminée, reprendra son travail normal.

Ensuite ben c'est tout à l'exception d'un tout petit détail: sur un Unix de base, quand la fonction est appelée à réception d'un signal X, la procédure est alors désarmée. Et ensuite si le pgm reçoit de nouveau un signal X, il se comporte alors par défaut.
Pour palier à ce pb, on a l'habitude, dans la fonction, de programmer un réarmement automatique
Exemple

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void myFunc(int sig)
{
    signal(sig, myFunc);
    ... blablabla...
}

Ainsi quand le pgm reçoit un signal X il est redirigé sur myFunc pendant que le mécanisme de détournement est désarmé. Puis la fonction commence son exécution et réarme alors elle-même le mécanisme.

Ce comportement de désarmement automatique n'est pas présent sous Linux. Si une fonction est armée, elle reste armée jusqu'à ce qu'on la désarme manuellement.

[maestroENSI]

salut
c'est trés interessant comme sujet et je vous conseille aussi d'inclure une connexion à votre shell c'est à dire le modéle client/serveur en utilisant les sokets

[nixmind]

Merci infiniment pour ta reponse.

Pour la question sur la facon de lancer mon shell, je lance pour le moment comme un programme a partir de mon shell par defaut.

j'ai bien note tes orientations, juste une question. comment je peut assigner la variable "int sig" pour eviter le "warning : unsused parrameter sig) lors de la compilation?

je peut lui donner juste n'importe quelle valeur et ca n'aura pas d'influence sur le comportement de ma fonction "myFunc"?

merci encore.

[Sve@r]

j'ai bien note tes orientations, juste une question. comment je peut assigner la variable "int sig" pour eviter le "warning : unsused parrameter sig) lors de la compilation?

je peut lui donner juste n'importe quelle valeur et ca n'aura pas d'influence sur le comportement de ma fonction "myFunc"?

Amusant. Effectivement, la variable "int sig" est impérative car elle sert à stocker le signal reçu. Mais si tu ne l'utilises pas, alors elle devient inutile et perçue comme telle par le compilo.

A mon avis, la meilleure chose à faire est de mettre la ligne de réarmement "signal(sig, myFunc)" en début de code de myFunc(). Même si ça ne sert pas sous Linux, ça rend ton programme portable sur Unix où elle est nécessaire et ça a l'avantage d'utiliser la variable donc plus de warning à la compilation...

[mickael633]

Bonsoir

Regardes la fonction ioctl. Elle permet de parametrer certaines options de ton terminal. Entre autres tu peux désactiver les signaux et récuperer les l'entrée sans que celle-ci soit bufferisée (ICANON), tres pratique pour gérer les touches fléchées.