Forum Programmation.c Gestion du joker '*'

Posté par  (site web personnel) .
Étiquettes : aucune
0
15
avr.
2005
Bonjour !
Comment faire pour gérer le fait qu'un utilisateur peut appeler un programme en le faisant suivre d'une * pour qu'il traite tous les fichiers d'un répertoire ?

J'ai essayé en considérant que unix remplacait l'étoile par une suite d'arguments mais ca ne semble pas être le cas .....

  • # Mais si

    Posté par  (site web personnel) . Évalué à 3.

    J'ai essayé en considérant que unix remplacait l'étoile par une suite d'arguments mais ca ne semble pas être le cas...
    Le shell remplace * par les fichiers disponibles non cachés, a condition qu'il y en ait, sinon * reste.

  • # re

    Posté par  . Évalué à 1.

    la gestion de ces caractère spéciaux est normalement faites par le shell qui substitue * au listing du répertoire lors de l'appel à exec().

    Tu n'as pas à gérer ça toi meme

  • # ah

    Posté par  (site web personnel) . Évalué à 1.

    Donc d'après ce que vous me dites je peux faire simplement

    for (i=1; i<argc; ++i) {
    printf("%s\n", argv[i]);
    }

    pour lister les arguments ?

    • [^] # Re: ah

      Posté par  (site web personnel) . Évalué à 2.

      Personnellement je fais
      for(i=0;argv[i];i++)
      printf("%s\n", argv[i]);
      Enfin bon bref :)

      • [^] # Re: ah

        Posté par  . Évalué à 1.

        Petite coquille: initialiser i à 1 pour zapper le nom du programme:)

      • [^] # Re: ah

        Posté par  (site web personnel) . Évalué à 1.

        Personnellement je fais (...)

        du code moins lisible et plus difficile à maintenir. À chacun son truc.

        • [^] # Re: ah

          Posté par  (site web personnel) . Évalué à 3.

          et moins performant : le programme doit aller chercher l'élément i dans le tableau, ce qui prend plus de temps que directement comparer deux valeur... je sais c'est imperceptible mais bon

          • [^] # Re: ah

            Posté par  (site web personnel) . Évalué à 2.

            Je suis pas tout à fait convaincu.
            T'as juste une zone mémoire à aller chercher, au lieu de deux si jamais t'es pas dans le cache.
            Enfin ca dépend des cas
            Enfin.....
            Je ne suis qu'un petit dévelopeur
            Enfin bon comme tu le disais c'est impérceptible :)

        • [^] # Re: ah

          Posté par  (site web personnel) . Évalué à 2.

          moins lisible?
          Ahum
          Chacun son goùt de la lisibilité je vois pas en quoi ca l'est moins:p
          Et pis c'est une habitude à prendre pour les tableaux qu'on a pas la longueur de celui ci (meme si ici on l'a certe)

          • [^] # Re: ah

            Posté par  (site web personnel) . Évalué à 2.

            A mon avis, penser de la sorte est une mauvaise habitude. Je suis même assez étonné qu'il n'y ai pas de segmentation fault. Si on dépasse la taille d'un tableau, cela pose un problème quand même... non ?

            si je fais

            int i;
            double *liste = (double)malloc(10 * siezof(double));
            for (i = 0; i < 10; i++)
            liste[i] = i + 1;
            for (i = 0; liste[i]; i++)
            printf("%f", liste[i]);

            il devrait y avoir une erreur dans le second for. Peut-être que dans argv, le dernier élément est toujours nul, alors là d'accord, mais je trouve mauvais de procéder de la sorte pour tous les tableaux.

            • [^] # Re: ah

              Posté par  (site web personnel) . Évalué à 3.

              Tu as tout à fait raison
              argv se termine par NULL,
              Et ca fait partie des habitudes à faire de le faire pour tout amha
              (remarque pour un pointeur sur un double j'accorde que ca va être dur....)
              Enfin bon toute chaine de caractères se termine par \0, donc de meme tout tableau de pointeurs doit se terminer par un null, ca permet d'avoir des tableaux à taille variable sans avoir à gérer de variable de taille (c'est deja assez le bordel dans les 'gros' progs comme ca :p)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.