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.

[nixmind]

Merci pour vos reponses!

J'ai pu gerer au moins le Ctrl + C, qui ne tue pas le processus fils(mon mini shell). mais deja ma fonction "handle_signal" marche bien, et ainsi je vais essayer de prgresser en essayant plusieurs choses. Surtout a pres ce ce minishell1, je dois realiser un minishell2, ou je dois cette fois gerer encore plusieurs options(les touches flechees, tabulations, et bien d'autres que je connais pas encore). Donc la j'aurai plus besoin de votre experience en prog.

Toutefois j'ai une autre preoccupation dont je prie de ne pas m'en tenir rigueur si je commets une erreur de poser le probleme ici plutot que d'ouvrir une nouvelle discussion.

En fait je dois programmer un client et serveur de communication. Le serveur doit etre lance en premier et affiche son PID apres le lancement. Le client prend comme parametres le PID du serveur et une chaine de caracteres. Le client doit communiquer au serveur la chaine passee en parametre et le serveur doit l'afficher. Bien que je dois gérer les valeurs de retour d'appel systèmes, les fonctions perror() et strerror() ne sont pas autorisées sur ce projet(Mais j'ai l'habitude gerer et d'afficher mes messages d'erreur sans utiliser ces focntions, donc c'est pas tres important ce details, juste qu'il fait partie du sujet).
comme details pour la gestion du projet,

La communication entre le client et le serveur doit se faire uniquement a l'aide des signaux. Le serveur doit afficher la chaine rapidement : 15 secs pour 100 chars c'est trop long. Il faut traiter plusieurs clients a la suite. J'ai droit a une variable globale par programme (a justifier). je n'ai le droit qu'aux signaux SIGUSR1 et SIGUSR2.
Options:
Gestion des erreurs de transmission et reemission. Gestion de conflits entre clients simultanes. Gestion correcte des ressources (temps d'utilisation CPU...)

Voila c'est un peu ca le sujet. Il ne s'agit de developper une appli client/serveur, mais d'ecrire deux programmes qui fonctioneront en client et en serveur comme explique plus haut, le language de programmation etant le C et les programmes seront compiles sous UNIX.

Merci emcore pour votre attention.

[zouuc]

J'ai du faire un minitalk, l'idée est d'utiliser le bit à bit pour envoyer les informations, une foi qu'elle est reçue, tu renvois un signale pour dire que tu peux en envoyer une nouvelle, ainsi de suite.

Bonne chance.

[matafan]

Oui transmission bit à bit avec SIGUSR1 pour un 0 et SIGUSR2 pour un 1. Ton handler enregistré par sigaction() reçoit en paramètre un singinfo_t qui contient entre autre le PID du process qui a émis le signal, donc avec ça tu peux gérer plusieurs clients.

Le plus délicat ça sera de définir ton protocole de communication.

[nixmind]

Salut!

merci pour ta reponse, mais si tu pouvais etre un lus explicite. En fait je sais bien mipuler le binaire, mais comment est ce aue je dois traiter exactement l'information a envoyer, et les envoies simultanes?

Merci d'etre un peu plus claire et si possible un petit algo, ne serait ce qu'en language humain.

[zouuc]

Désolé, je ne sais plus exactement comment faire, je me rappel juste avec quoi j'ai fais ça :/
Mais normalement avec la direction dans laquelle nous t'orientons, tu devrais trouver tout ce qu'il te faut pour terminer ton projet

De mémoire, tu décomposes le message envoyé en char. Tu envois chaque char bit par bit de l'autre côté tu recompose le char, une foi que le char est bien réceptionné tu réceptionnes le suivant ou alors la transmission est terminée car tu as transmis tous les char du message.
Pour envoyer les différents bit, il faut utiliser SIGUSR1 et SIGUSR2 pour 0 et 1 comme l'a dit matafan.

Je me rappel que j'avais du placer un usleep(pas trop elevé) de manière intelligente. Mais comme je n'ai pas accès à mon travail pour le moment, je ne peux pas aider plus :/ Mais ça n'est pas un mal, avec tout ça tu devrais trouver si tu cherches bien

[matafan]

En fait on ne peut pas vraiment utiliser kill() pour envoyer le signal, parce qu'avec kill() le signal envoyé est perdu si le process cible bloque le signal (ce qui sera le cas si le server est déjà dans le signal handler).

Par contre on peut utiliser sigqueue() à la place de kill(), qui ne perd pas de signal : si le signal et bloqué dans le process cible alors le signal est mis en queue, et le process cible le verra quand il démasquera le signal (i.e. quand il sortira de son signal handler).

Et il se trouve que sigqueue(), en plus du signal, permet d'envoyer un int de donnée en plus du signal (c'est le 3ème argument). Donc on peut en profiter pour envoyer un caractère d'un coup (ou même 4 d'ailleurs) plutôt que d'envoyer chaque caractère bit par bit.

Cette optimisation mise à part, la logique est la suivante :

Dans le client :

- Pour chaque char de la chaine à envoyer
..- Pour chaque bit du char
....- Utiliser sigqueue() pour envoyer un SIGUSR1 ou SIGUSR2 suivant qu'on veut envoyer un 0 ou un 1

Dans le serveur, on utilisera une structure de données globale (par exemple une liste chainée) qui permettra d'enregistrer, pour chaque client, les données reçues jusqu'à présent. Les éléments de cette structure permettront de "se souvenir" d'où on en est entre deux appels du handler, et devront forcément contenir :

- Le pid du client
- La chaine de caractères contenant les données reçues
- A quel char on en est dans cette chaine
- A quel bit on en est dans ce char

Il n'y a pas de problème d'accès concurrents sur ces données, puisque les signaux USR1 et USR2 seront masqués quand le handler est appelé.

Ensuite la logique est la suivante :

- Installer le signal handler pour SIGUSR1 et SIGUSR2 (mettre SA_SIGINFO dans sa_flags, et mettre SIGUSR1 et SIGUSR2 dans le sa_mask)
- Boucler indéfiniment ( for ( ; ; ) sleep(1); )
- Dans le signal handler
..- Récupérer les données pour le pid concerné
..- Ajouter le bit reçus dans les données du pid concerné

Pour signaler la fin des données, on pourra par exemple envoyer un caractère nul ('\0'), que le signal handler devra détecter.

[matafan]

Bah non, quand-même pas. Bien que super intéressant comme sujet (je me suis amusé une fois à coder un Morse avec trait/point remplacés par SIGUSR1/SIGUSR2), ce n'est pas le but de son TP quoi.

Si justement ça m'en a tout l'air, puisque "La communication entre le client et le serveur doit se faire uniquement a l'aide des signaux". Et je ne vois pas en quoi les signaux seraient utiles si on utilisait des sockets.

[Sve@r]

Si justement ça m'en a tout l'air, puisque "La communication entre le client et le serveur doit se faire uniquement a l'aide des signaux". Et je ne vois pas en quoi les signaux seraient utiles si on utilisait des sockets.

Oups t'as raison. J'avais pas vu la partie "par signaux". J'ai donc supprimé mon post erroné...

Merci d'etre un peu plus claire et si possible un petit algo, ne serait ce qu'en language humain.

Ben un truc de ce type: tu dois envoyer "bonjour". Le caractère "b" se code 0x62 donc 01100010. Le caractère "o" se code 0x6F donc 01101111. Le caractère "n" se code 01101110 etc etc.
Donc t'envoies 01100010 01101111 01101110 en codant "0" par SIGUSR1 et "1" par SIGUSR2 en rafale de kill. En utilisant la technique de Matafan de mise en file d'attente pour éviter d'en perdre de l'autre coté...

Dans le serveur, on utilisera une structure de données globale (par exemple une liste chainée) qui permettra d'enregistrer, pour chaque client, les données reçues jusqu'à présent. Les éléments de cette structure permettront de "se souvenir" d'où on en est entre deux appels ...

Je me demande comment le serveur va pouvoir faire la différence entre "SIGUSR reçu de client1" et "SIGUSR reçu de client2" dans le cas où les 2 clients sont lancés en parallèle...

Et il se trouve que sigqueue(), en plus du signal, permet d'envoyer un int de donnée en plus du signal (c'est le 3ème argument). Donc on peut en profiter pour envoyer un caractère d'un coup (ou même 4 d'ailleurs) plutôt que d'envoyer chaque caractère bit par bit.

Ou alors utiliser cet int pour faire passer le pid du client...

[nixmind]

Salut les gars!

J'ai pas pu tomber sur vos precieux messages jusqu'a cet instant.

Et je constate que vos dernieres suggestions sont vraiment enrichissantes. La logique des listes chainees convient aussi bien pour moi, et j'aimerais a la suite de ce message que Matafan me dise si j'ai compris le principe comme il l'attendais.
En fait voici comment je vois le truc.
Je cree une structure domaine a la maniere indiquee par Matafan, et je code une petite fonction dont le but sera de remplir ma structure a chaque appel.
Les elements ont entres en fin de liste, pour ainsi gerer l'ordre d'arriver des messages pour l'affichage. Ainsi Quand le serveur recois un signal, il emplit la chaine correspondant au PID concerne, et si le PID n'est pas celui de l'element en cours, il cree une nouvelle structure et l'insere en tete de liste, il fait ainsi pour tous les clients dont il recois les signaux, et apres il affiche la liste element par element.

J'espere que c'est bien comme cela que ca finctionne, si non merci de repreciser ce qui n'a pa ete bien compris.

J'ai quand meme quelques autres questions: En fait pour remplir ma structure je dois la malloc, et je dois la malloc le char * qui continedra les donnees recues car la chaine de caractaire n'est pas passee en dur au serveur ( les messages sont envoyes char par char et bit par bit). De ce fait comment connaitre la taille dont je dois malloc ce champ? Puisque jusqu'ici ma solution etais de coder le message cote client et l'envoyer char par char, bit par bit, puis cote serveur de decoder le message et afficher les char au fur et mesure qu'il en recoit.
Aussi pour le projet nous n'avons droit qu'a certains appels systeme dont sigqueue ne fait pas partie; du coup la gestion de plusieurs clients simultanes devient impossible avec le seul kill.

J'aimerais aussi bien comprendre cette expression qu'a utliser matafan :
Installer le signal handler pour SIGUSR1 et SIGUSR2 (mettre SA_SIGINFO dans sa_flags, et mettre SIGUSR1 et SIGUSR2 dans le sa_mask)
- Boucler indéfiniment ( for ( ; ; ) sleep(1); )
- Dans le signal handler
..- Récupérer les données pour le pid concerné
..- Ajouter le bit reçus dans les données du pid concerné
Que veut dire exactement "installer signal handler pour SIGUSR1 et SIGUSR2 (mettre SA_SIGINFO dans sa_flags, et mettre SIGUSR1 et SIGUSR2 dans le sa_mask)" ?

Merci

[zouuc]

Pour connaitre la taille à malloc, tu peux strlen la chaine de base que tu veux transmettre. Avant de la transmettre, tu envoi la longueur de la chaine que tu auras transformé (int => char*) bit par bit aussi.

Je crois que ça peut marcher comme ça aussi.

[nixmind]

Ouais Zouc!

Mais juste que ca va faire trop de "kill" (32 pour envoyer le PID, 32 pour envoyer la longueur de la chaine, et ensuite la chaine de caractere bit par bit). De plus vue que j'qi pqs le droit a sigqueu, je ne vois comment gerer plusieurs cleintys en meme temps, car le serveur ne saura toujrs pas de qui vient le signal, a moins d'envoyer le pid autant de fois qu'il faut envoyer de signal. Ce qui devient trs lourd.

Pour le moment je vais deja essayerde bien gerer un seul client, et j'espere que j'qurqi l'qstuce pour gerer plusieurs client avec kill d'ici la.

Mais j'aimerais toujours bien comprendre l'expression :"Installer le signal handler pour SIGUSR1 et SIGUSR2 (mettre SA_SIGINFO dans sa_flags, et mettre SIGUSR1 et SIGUSR2 dans le sa_mask)" qui figure dqns les mqn et que j'qi retrouvee ici, sans pouvoir la decortiquer.

Merci encore et a bientot.