UNIX, AIX, du bon usage de la commande system

Version imprimable

la commande "ls /et" renvoie 2 sur mon unix aix et renvoie 512 avec la commande system. Comment faire pour avoir 2 ???

pour le source:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 #include <stdio.h> #include <stdlib.h> #include <string.h> int main() { char cmd[256] ; int num; strcpy (cmd, "ls /et") ; num = system(cmd); printf("int : %d\n",num); return (num) ; }
pour la compilation :
Code:

1 2 3 /usr/vac/bin/xlc -c main.c /usr/vac/bin/xlc -o main main.o
Merci d'avance.

08/02/2008, 15h45
souviron34

euh....

la sortie de ls n'EST PAS la sortie de system...

la sortie de system est (voir le man page) en gros succès ou erreur.

Pour obtenir la sortie de ls, pas vraiment de moyen direct. Un pipe, un script qui transforme la valeur de sortie en variable qu'après tu exportes,.....
08/02/2008, 15h50
Jean-Marc.Bourguet

Citation:

Envoyé par souviron34

Pour obtenir la sortie de ls, pas vraiment de moyen direct. Un pipe,

Utiliser popen()/pclose() plutot que pipe() si possible.

Citation:

un script qui transforme la valeur de sortie en variable qu'après tu exportes,.....

Tu es distrait, exporter une variable vers le processus pere, ca me semble impossible.
08/02/2008, 16h01
Emmanuel Lecoester

l'exemple du ls c'est pour le forum. J'ai un binaire qui renvoie 0, 1,... 200

en gros avec la commande system j'ai 0 ou n'importe quoi :aie:
08/02/2008, 16h10
nicolas.sitbon

Citation:

Envoyé par souviron34

euh....

la sortie de ls n'EST PAS la sortie de system...

la sortie de system est (voir le man page) en gros succès ou erreur.

man system() :

Citation:

La valeur renvoyée est 127 si l'appel système execve() pour /bin/sh échoue, -1 si une autre erreur se produit, ou le code de retour de la commande sinon.
08/02/2008, 16h22
Jean-Marc.Bourguet

POSIX demande que le resultat de system soit la valeur retournee par waitpid. Donc il faut
utiliser WIFEXITED et ses copains pour voir la cause de termination et WEXITSTATUS si WIFEXITED retourne qqch de non nul pour avoir le code retourne. (Il y a WIFSIGNALED et WTERMSIG quand la cause de termination est un signal).

Citation:

Envoyé par Jean-Marc.Bourguet

POSIX demande que le resultat de system soit la valeur retournee par waitpid. Donc il faut
utiliser WIFEXITED et ses copains pour voir la cause de termination et WEXITSTATUS si WIFEXITED retourne qqch de non nul pour avoir le code retourne. (Il y a WIFSIGNALED et WTERMSIG quand la cause de termination est un signal).

Tu aurais un lien ou encore mieux un exemple de réécriture de commande system ?

j'ai trouvé çà mais çà me semble un peu lourd :oops:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
/* like system(), but executes the specified command as a background
 * job, returning the pid of the shell process (which is also the pgrp
 * of the job, suitable for kill_job etc.)
 * If INFD, OUTFD or ERRFD are non-NULL, then a pipe will be opened and
 * a descriptor for the parent end of the relevent pipe stored there.
 * If any of these are NULL, they will be redirected to /dev/null in the
 * child.
 * Also closes all FDs > 2 in the child process (an oft-overlooked task)
 */
 
pid_t spawn_background_command(const char *cmd,
                               int *infd, int *outfd, int *errfd)
{
    int nullfd = -1;
    int pipefds[3][2];
    int error = 0;
 
    if (!cmd)
        return errno = EINVAL, -1;
 
    pipefds[0][0] = pipefds[0][1] = -1;
    pipefds[1][0] = pipefds[1][1] = -1;
    pipefds[2][0] = pipefds[2][1] = -1;
 
    if (infd && pipe(pipefds[0]) < 0)
        error = errno;
    else if (outfd && pipe(pipefds[1]) < 0)
        error = errno;
    else if (errfd && pipe(pipefds[2]) < 0)
        error = errno;
 
    if (!error && !(infd && outfd && errfd))
    {
        nullfd = open("/dev/null",O_RDWR);
        if (nullfd < 0)
            error = errno;
    }
 
    if (!error)
    {
        pid_t pid = spawn_job(0, -1);
        switch (pid)
        {
            case -1: /* fork failure */
                error = errno;
                break;
 
            case 0: /* child proc */
 
                dup2(infd ? pipefds[0][0] : nullfd, 0);
                dup2(outfd ? pipefds[1][1] : nullfd, 1);
                dup2(errfd ? pipefds[2][1] : nullfd, 2);
                closeall(3);
 
                execl("/bin/sh","sh","-c",cmd,(char*)NULL);
 
                _exit(127);
 
            default: /* parent proc */
 
                close(nullfd);
                if (infd)
                    close(pipefds[0][0]), *infd = pipefds[0][1];
                if (outfd)
                    close(pipefds[1][1]), *outfd = pipefds[1][0];
                if (errfd)
                    close(pipefds[2][1]), *errfd = pipefds[2][0];
 
                return pid;
        }
    }
 
    /* only reached if error */
 
    {
        int i,j;
        for (i = 0; i < 3; ++i)
            for (j = 0; j < 2; ++j)
                if (pipefds[i][j] >= 0)
                    close(pipefds[i][j]);
    }
 
    if (nullfd >= 0)
        close(nullfd);
 
    return errno = error, (pid_t) -1;
}

08/02/2008, 22h33
souviron34

Citation:

Envoyé par nicolas.sitbon

man system() :

man system (pas les man pages traduites, le vrai original ;))

dit :

Citation:

RETURN VALUE
If command is a null pointer, system() shall return non-zero to indicate that a command processor is avail-
able, or zero if none is available. The system() function shall always return non-zero when command is NULL.

If command is not a null pointer, system() shall return the termination status of the command language inter-
preter in the format specified by waitpid(). The termination status shall be as defined for the sh utility;
otherwise, the termination status is unspecified. If some error prevents the command language interpreter
from executing after the child process is created, the return value from system() shall be as if the command
language interpreter had terminated using exit(127) or _exit(127). If a child process cannot be created, or if
the termination status for the command language interpreter cannot be obtained, system() shall return -1 and
set errno to indicate the error.

ERRORS
The system() function may set errno values as described by fork() .

In addition, system() may fail if:

ECHILD The status of the child process created by system() is no longer available.

The following sections are informative.

EXAMPLES
None.

APPLICATION USAGE
If the return value of system() is not -1, its value can be decoded through the use of the macros described in
<sys/wait.h>. For convenience, these macros are also provided in <stdlib.h>.

Mauvaise traduction... :aie:

Pas le code de retour de la commande, le code de retour DU SHELL.

Or, man sh donne :

Citation:

EXIT STATUS
For the shell's purposes, a command which exits with a zero exit status has succeeded. An exit status of zero
indicates success. A non-zero exit status indicates failure. When a command terminates on a fatal signal N,
bash uses the value of 128+N as the exit status.

If a command is not found, the child process created to execute it returns a status of 127. If a command is
found but is not executable, the return status is 126.

If a command fails because of an error during expansion or redirection, the exit status is greater than zero.

Shell builtin commands return a status of 0 (true) if successful, and non-zero (false) if an error occurs
while they execute. All builtins return an exit status of 2 to indicate incorrect usage.

Bash itself returns the exit status of the last command executed, unless a syntax error occurs, in which case
it exits with a non-zero value. See also the exit builtin command below.

:mrgreen:

Citation:

Envoyé par Jean-Marc.Bourguet

POSIX demande que le resultat de system soit la valeur retournee par waitpid. Donc il faut
utiliser WIFEXITED et ses copains pour voir la cause de termination et WEXITSTATUS si WIFEXITED retourne qqch de non nul pour avoir le code retourne. (Il y a WIFSIGNALED et WTERMSIG quand la cause de termination est un signal).

Non, c'est le FORMAT qui doit etre celui du waitpid. La VALEUR est normalement celle du retour de sh.... ;)
08/02/2008, 23h05
nicolas.sitbon

Ah oui effectivement autant pour moi, je viens aussi de vérifier dans le Stevens et :

Citation:

the return value from system() is the termination status of the shell, in the format specified for waitpid()

Pour en revenir à cette erreur de traduction, elle est répercutée aussi dans l'ouvrage de Christophe Blaess, logique puisque c'est lui qui a le plus traduit les man pages.
Merci pour ces précisions.

Citation:

Envoyé par elecoest

l'exemple du ls c'est pour le forum. J'ai un binaire qui renvoie 0, 1,... 200

en gros avec la commande system j'ai 0 ou n'importe quoi :aie:

2 solutions que j'ai trouvées :
soit tu fais sortir ton binaire (si ton binaire tu peux lui rajouter un fprintf(stdout) à la fin) dans un fichier tempo, et tu fais :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 FILE *f=NULL ; char command[500] ; int s, result ; sprintf ( command, "./monbinaire > ./sortie.txt"); s = system(command); if ( (f = fopen("./sortie.txt", "r")) != NULL ) { fgets ( command, 500, f); sscanf ( command, "%d", &result); fclose(f); sprintf ( command, "rm -f ./sortie.txt"); s = system(command); }
soit, si tu connais ton nom de binaire au début, par exemple, tu peux faire (sans rien changer au binaire ui ressort une valeur numérique):

Code:

./monprog `./monbinaire`

quand tu le lances, et dans ton prog monprog tu as
Code:

1 2 3 4 5 6 7 int main ( int argc, char **argv ) { ...... sscanf ( argv[1], "%d", &result); .... }

11/02/2008, 11h25
Emmanuel Lecoester

inconvénient c'est que ce n'est pas un binaire mais un .so. C'est une technique Oracle pour lancer des ordres host : tu encapsules la commande system dans une procédure externe écrite en C.

Possibilité 1 : pas d'accès disque (les admins système vont raler) et l'accès peut être concurrent.

Possibilité 2 : pas possible avec le .so (du moins je pense)

Merci pour votre aide. je vais en rester à mon cas : si <> 0 alors pas bon :P
11/02/2008, 11h44
DaZumba
Citation:

Envoyé par souviron34

Non, c'est le FORMAT qui doit etre celui du waitpid. La VALEUR est normalement celle du retour de sh....

Ben oui, mais la valeur de retour de sh est celle de la derniere commande executee... Donc, a moins que sh n'ait pas pu demarrer, tu recuperes bien le retour de ta commande !
Un exemple est toujours meilleur qu'un long discours:
Un programme qui renvoit une valeur:
Code:

1 2 3 4 int main(void) { return 42; }
et un programme qui appelle celui au-dessus et affiche la valeur renvoyee:
Code:

1 2 3 4 5 6 7 8 9 10 11 #include <stdio.h> #include <stdlib.h> #include <sys/wait.h> int main(void) { int ret = system("./toto"); printf("toto returned %d.\n", WEXITSTATUS(ret)); return 0; }
Ca me sort:

Citation:

toto returned 42.

C'est un comportement conforme a POSIX, je pense.
11/02/2008, 14h20
souviron34

Citation:

Envoyé par DaZumba

Ben oui, mais la valeur de retour de sh est celle de la derniere commande executee... Donc, a moins que sh n'ait pas pu demarrer, tu recuperes bien le retour de ta commande !
....
C'est un comportement conforme a POSIX, je pense.

je reprends le man sh plus haut, et tu peux le faire sur ton système :

Citation:

EXIT STATUS
For the shell's purposes, a command which exits with a zero exit status has succeeded. An exit status of zero indicates success. A non-zero exit status indicates failure. When a command terminates on a fatal signal N, bash uses the value of 128+N as the exit status.

If a command is not found, the child process created to execute it returns a status of 127. If a command is found but is not executable, the return status is 126.

If a command fails because of an error during expansion or redirection, the exit status is greater than zero.

Shell builtin commands return a status of 0 (true) if successful, and non-zero (false) if an error occurs while they execute. All builtins return an exit status of 2 to indicate incorrect usage.
Bash itself returns the exit status of the last command executed, unless a syntax error occurs, in which case it exits with a non-zero value. See also the exit builtin command below.

si donc tu te sers de perror ou errno, il sera setté à la bonne valeur...

TIENS D'AILLEURS VOICI LA SOLUTION !!!!

Utiliser errno juste après system() devrait directment donner le résultlat, non ? d'après ce qui est indiqué dans le man sh...

Mais la doc est claire : pour un SHELL, 0 est un succès, TOUTE AUTRE VALEUR est un échec...
11/02/2008, 15h14
DaZumba

Tu n'as pas mis l'emphase la ou il fallait dans ta citation du man:

Citation:

Envoyé par man sh

For the shell's purposes, a command which exits with a zero exit status has succeeded. An exit status of zero indicates success. A non-zero exit status indicates failure. When a command terminates on a fatal signal N, bash uses the value of 128+N as the exit status.

Ici, on se moque de l'interpretation faite par la shell du code de retour. Tout ce qu'on veut, c'est recuperer le retour d'une commande via le retour de system(). Et c'est exactement ce que WEXITSTATUS() fait. Dans mon exemple, j'envois 42, j'obtiens 42. C'est ce le P.O. voulait, non ?
11/02/2008, 15h58
Emmanuel Lecoester

je confirme, la solution proposée par DaZumba fonctionne.:yaisse2:

Merci à tous.
11/02/2008, 17h03
souviron34

et je pense que errno fonctionne aussi, et est encore plus portable, non ?
11/02/2008, 17h06
Médinoc

Au contraire, je ne vois pas pourquoi errno marcherait: La valeur d'errno doit correspondre à des codes précis, que le code de retour d'une application n'est en aucun cas tenu de respecter.

Par contre, errno peut peut-être indiquer si l'appel à system() a réussi ou non (programme non trouvé, etc.) mais ça m'étonnerait, vu que ça passe par le shell.
11/02/2008, 17h08
souviron34

ben je pense que errno (pas perror) contient juste le retour de la commande...
11/02/2008, 17h11
Médinoc

Mais cela briserait le contrat d'errno, avec strerror() et perror()...
11/02/2008, 17h16
souviron34

ok j'ai verifie, tu as raison....