Redirection de la sortie standard

**Dud225** · 09/04/2007, 22h35

J'ai récupéré le code d'un mini-shell que quelqu'un a fait et je me pose des questions sur la façon d'avoir programmé la redirection de la sortie standard :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
else if(strcmp(arg2,">")==0 && arg3 != '\0')
{
     int fichier = open(arg3,O_RDWR|O_CREAT, 0600);
     pid = fork();
 
     if(pid==0)
     {
         close(1);
         dup(fichier);
         close(fichier);
         execlp(arg1,arg1,NULL);
         printf("Commande inexistante : %s\n",arg1);
         exit(-1);
     }

Tout d'abord je ne suis pas sûr que ce code soit juste, donc n'hésitez pas à le corriger.
Je ne comprend pas bien pourquoi il y a close(fichier). Pour moi, si l'on ferme ce descripteur, c'est un peu comme si l'on faisait un free c'est à dire que l'on ne pourra plus accéder à ce descripteur. Et si l'on ne peut plus y accéder, je vois mal comment on peut y écrire des données!

Et sinon, j'ai changé les permission dans la primitive open et j'ai constaté que ça ne changeait rien que je mettre 0777 ou 0000! A quoi est-ce dû?

**Médinoc** · 10/04/2007, 11h16

dup() tout court sur un descripteur, ça me parait bizarre : Normalement, on garde le résultat de dup(), ou on utilise dup2()...

En l'occurence, je pense qu'il aurait fallu utiliser dup2() avec 1 (ou plutôt STDOUT_FILENO) dans l'un des paramètres.

**Jean-Marc.Bourguet** · 10/04/2007, 11h24

Si j'ai bonne memoire, dup reutilise le plus petit descripteur libre. L'auteur suppose que donc 0 est toujours ouvert (ou bien il l'a ouvert avant).

L'utilisation de dup2 serait plus claire (mais si j'ai bonne memoire, dup2 est nettement posterieur a dup).

**Foobar1329** · 10/04/2007, 11h55

Hello,

Envoyé par Dud225

J'ai récupéré le code d'un mini-shell que quelqu'un a fait et je me pose des questions sur la façon d'avoir programmé la redirection de la sortie standard :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
else if(strcmp(arg2,">")==0 && arg3 != '\0')
{
     int fichier = open(arg3,O_RDWR|O_CREAT, 0600);
     pid = fork();
 
     if(pid==0)
     {
         close(1);
         dup(fichier);
         close(fichier);
         execlp(arg1,arg1,NULL);
         printf("Commande inexistante : %s\n",arg1);
         exit(-1);
     }

Tout d'abord je ne suis pas sûr que ce code soit juste, donc n'hésitez pas à le corriger.
Je ne comprend pas bien pourquoi il y a close(fichier). Pour moi, si l'on ferme ce descripteur, c'est un peu comme si l'on faisait un free c'est à dire que l'on ne pourra plus accéder à ce descripteur. Et si l'on ne peut plus y accéder, je vois mal comment on peut y écrire des données!

Et sinon, j'ai changé les permission dans la primitive open et j'ai constaté que ça ne changeait rien que je mettre 0777 ou 0000! A quoi est-ce dû?

Tout d'abord, ce qui me gêne, la variable arg3 : elle est comparée à un entier dans l'expression conditionnelle puis passée en argument à open() qui attend char *. On peut supposer qu'il s'agit de *arg3 != '\0'.

Sinon le code est correct. fork() créé un processus fils, le close(1) ferme le stdout de ce processus nouvellement créé, le dup(fichier) redirige la sortie standard vers le fichier 'fichier' (ou plutôt, créé un nouveau stdout en utilisant 'fichier'). N'ayant plus besoin du fichier 'fichier', normal, on a obtenu notre stdout, on peut fermer 'fichier'. execlp() execute la commande identifiée par arg1 dans le processus fils. Si la commande est inconnue, on peut légitimement écrire sur le stdout (qu'on a redirigé) du processus fils avec printf(). Donc aucun problème.

Ton pb de compréhension vient de dup(). Pour cela, il faut aller chercher la réponse dans la documentation de la fonction fcntl() après avoir lu tout aussi attentivement celle de dup().

http://www.opengroup.org/onlinepubs/...tions/dup.html
http://www.opengroup.org/onlinepubs/...ons/fcntl.html

A+

**Médinoc** · 10/04/2007, 11h58

Correct, mais sale. Très sale.
Utiliser dup2() est plus propre. Utiliser les defines STD*_FILENO est plus propre également.

**Foobar1329** · 10/04/2007, 12h04

Hello,

Envoyé par Médinoc

Correct, mais sale. Très sale.
Utiliser dup2() est plus propre. Utiliser les defines STD*_FILENO est plus propre également.

Ah, mais je n'ai pas dit qu'il ne fallait pas utiliser dup2()

. Le lecteur qui lit attentivement la doc indiquée par les liens de mon msg précédent devrait même utiliser dup2() en toute logique.

A+

**fearyourself** · 10/04/2007, 16h38

Envoyé par Médinoc

Correct, mais sale. Très sale.
Utiliser dup2() est plus propre. Utiliser les defines STD*_FILENO est plus propre également.

Je ne vois pas pourquoi c'est sale.

L'utilisation de dup est correcte et ne nécessite pas l'utilisation de dup2 dans ce cas précis. Dans un cas général, il va sans dire qu'on est d'accord...

Par contre, je suis d'accord sur l'utilisation des STD*_FILENO.

Jc

**Médinoc** · 10/04/2007, 17h57

Ben si, fermer un descripteur pour réouvrir autre chose magiquement par-dessus, c'est sale.

D'ailleurs, si le descripteur 0 était fermé avant, ça échouerait.

D'ailleurs, je ne sais pas du tout si la norme POSIX garantit que le descripteur nouvellement ouvert sera forcément le plus petit disponible (bien que c'est possible, chez POSIX)...

**Foobar1329** · 10/04/2007, 18h56

Envoyé par Médinoc

Ben si, fermer un descripteur pour réouvrir autre chose magiquement par-dessus, c'est sale.

Je pensais que tu estimais que dup() était "sale" pour le seul manque de lisibilité. Que crois-tu que fait dup2() ? Il fait la même chose que dup(), il ferme un descripteur pour en ouvrir un autre par dessus, sans magie

.

Envoyé par Médinoc

D'ailleurs, si le descripteur 0 était fermé avant, ça échouerait.

Oui, mais un dup2( <my file descriptor>, 1) ou dup2( <my file descriptor>, STDOUT_FILENO) ne changerait rien.

Envoyé par Médinoc

D'ailleurs, je ne sais pas du tout si la norme POSIX garantit que le descripteur nouvellement ouvert sera forcément le plus petit disponible (bien que c'est possible, chez POSIX)...

C'est garanti.

A+

**Dud225** · 10/04/2007, 19h31

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
int fichier=0;
pid_t pid=0;
 
...
 
else if(strcmp(arg2,">")==0 && *arg3 != '\0')
{
     fichier = open(arg3,O_RDWR|O_CREAT,S_IRWXU);
     pid = fork();
 
     if (pid==0)
     {
         close(STDOUT_FILENO);
         dup2(fichier,STDOUT_FILENO);
         close(fichier);
         execlp(arg1,arg1,NULL);
         printf("Commande inexistante : %s\n",arg1);
         exit(-1);
     }

Voilà pour les puristes...

Je suis sincèrement très d'accord avec vous sur le fait qu'il est important de coder proprement et de prendre tout de suite de bonnes habitudes, mais je pense que le fond est au préalable plus important que la forme. Dans mon école, des mecs écrivent des programmes sans même finir le main par un "return 0" et notre prof de C ne dit rien, donc bon je me dit par là qu'il veut que prioritairement on comprenne les choses.

Donc merci Foobar1329, j'ai une réponse à ma question sur l'intérêt de dup(fichier). Mais bon, quand on compile (et quand on débute encore), on a du mal à voir l'importance de tels et tels fonctions lorsque l'on voit que quand on les enlève ça marche tout aussi bien (en apparence).

Mais je repose ma question en ce qui concerne les droits : ça ne change rien si je mets S_IRWXU (0777), S_IWUSR (0200) ou S_IXOTH (0001), le fichier est toujours créé avec les même droits : 0775! Comment cela se fait-il?

Redirection de la sortie standard

C

Vue hybride

Discussions similaires

Partager

Partager