Forum Linux.débutant Lancer un .out dans une console

Posté par  .
Étiquettes : aucune
0
3
nov.
2006
Bonjour, je suis étudiant en informatique. Je programme en C sur des stations de travail UNIX. Donc nous n'avons a disposition que emacs et le terminal X-TERM. Je me suis installé Mandriva 2007 free pour pouvoir travailler de la même façon qu'en cour. Pour ce qui est de la compilation, pas de problème, GCC fonctionne très bien. Le problème vient de l'éxecution du .out généré par la compilation. Quand je suis en cour je fais juste "a.out" (par exemple) et hop le programme s'éxécute, mais la, ca me met "command not found".
Que dois-je faire?

Merci à tous
  • # ./a.out

    Posté par  . Évalué à 5.

    c'est une question de variable PATH

    il faut faire ./a.out pour lancer l'exe depuis le répertoire courant.
  • # Spécifier le chemin?

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

    Par exemple, si tu n'a pas changer de répertoire depuis ta compilation :

    ./a.out
  • # Répertoire courant

    Posté par  . Évalué à -2.

    Deux solutions :

    - Rajoute le répertoire courant (.) dans le $PATH

    - Exécute ton a.out comme ceci : ./a.out
    • [^] # Re: Répertoire courant

      Posté par  . Évalué à 7.

      - Rajoute le répertoire courant (.) dans le $PATH


      Hmm, ça c'est un conseil à ne pas donner.
      • [^] # Re: Répertoire courant

        Posté par  . Évalué à 1.

        En effet.

        Il serait alors possible de confondre un exécutable "local" avec un exécutable "système", ce qui pourrait conduire à une "infection" du système (selon que l'exécutable local soit en réalité un root-kit/virus/etc).

        Mea culpa.
        • [^] # Re: Répertoire courant

          Posté par  . Évalué à 2.

          Exact, et en plus, même sans aller jusque là, si on fait l'erreur de placer le point en début de chaîne, alors les exécutables locaux seront exécutés en priorité, ce qui peut complètement compromettre tout ce qui est réalisé à base de scripts shells, ce qui est quand même légion sous Unix. Sans compter les heures de débogages perdues à ne pas comprendre qu'on ne lance pas toujours le même exécutable avec la même commande ...

          En outre, c'est un piège à éviter car non seulement c'est naturel à priori pour l'utilisateur, mais c'était également le comportement de DOS. Le nouvel utilisateur, habitué toutefois à la ligne de commande, contrairement aux plus jeunes d'entre nous, débarquait avec une floppée de (mauvaises) habitudes et avait tendance à vite remettre son "./" au début de son PATH pour retrouver le comportement orginal. C'est un peu comme le " alias dir='ls' " ... Il vaut mieux à la place prendre dès le départ les bons réflexes.

          Pire, sous DOS, il y avait plusieurs types d'exécutables. Les *.com étaient prioritaires par rapport aux *.exe et comme le statut de fichier caché se donnait grâce à un flag et pas par une politique de nommage, on a eu toute une génération de virus compagnons qui traînaient dans les différents répertoires du système ...
          • [^] # Re: Répertoire courant

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

            le mieux reste encore d'utiliser l'option -o pour ne pas avoir un sale a.out et d'appeler le programme "test" (capillotractage garanti).

            Bref, -o mon_prog c'est plutôt mieux comme nom, ça s'exécute simplement par ./mon_prog ensuite (après un éventuel chmod +x mon_prog)
            • [^] # Re: Répertoire courant

              Posté par  . Évalué à 2.

              C'est vrai que laisser traîner un a.out, c'est pas très propre, mais cela ne change au rien au problème de PATH.

              Il vaut donc mieux prendre l'habitude, effectivement, de nommer ses fichiers de sortie mais quand on code en C, il est carrément plus intelligent d'écrire tout de suite le Makefile associé. Pas long à écrire (surtout avec les expressions implicite), super facile à rappeler, et surtout, quand on fait "gcc test.c -o test", on a tendance à utiliser l'auto-complétion pour définir le nom de sortie, et il arrive toujours un moment ou l'on tape Entrée avant d'avoir tronqué l'extension. Et là, c'est "paf le fichier source".
              • [^] # Re: Répertoire courant

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

                ah oui, l'effacement de fichier source, à qui ce n'est pas arrivé /o\ (d'où l'intérêt de subversion systématique ou d'un gestionnaire de sources, même pour des petits changements).

                Sinon, je crains de ne pas avoir été clair : bannir le nom test pour un programme (c'est un mot réservé de bash, ksh aussi, donc bon en cumulant avec l'oubli du ./ devant, forcément ça ne sort rien...). Utiliser test1 au pire mais faire le Makefile tout de suite est effectivement une meilleure habitude.
              • [^] # Re: Répertoire courant

                Posté par  . Évalué à 2.

                Une bonne ressource pour apprendre l'art de faire son makefile ? Ou un outil newbie-friendly ? (pour prolonger le thread, et pour ma culture perso...)
                • [^] # Re: Répertoire courant

                  Posté par  . Évalué à 2.

                  Quand je tape "Makefile" dans Google, j'ai çà :

                  http://www.google.fr/search?hl=fr&q=Makefile&btnG=Re(...)

                  Je pense qu'il y a de quoi faire. Les trois premiers liens sont les plus pertinents à mon goût. Sinon, un Makefile, ça peut se résumer à une seule ligne. La seule chose qu'il faut retenir est cette structure :

                  cible: dependance1 dependance2 ...
                      commande


                  "cible" est le nom du fichier à générer. En tapant "make cible", make va vérifier si le fichier "cible" existe et si ce n'est pas le cas, alors il va exécuter "commande" pour le faire. On peut préciser plusieurs commandes successives, même sur plusieurs lignes, à conditions qu'elles soient tassées contre la ligne cible, et qu'elles débutent toutes par une tabulation.

                  Les dépendances sont optionnelles. Ce sont également des fichiers qui doivent à terme exister sur le disque mais qui peuvent ou non être spécifiés en tant que cibles dans le makefile. Si elles sont précisées, alors Make va non seulement vérifier l'existence du fichier cible, mais également celle des fichiers dont la cible est dépendante, en s'assurant également qu'ils soient plus anciens que la cible qui nous intéresse. L'exemple typique est celui-ci :

                  toto: toto.c
                      gcc toto.c -o toto


                  On cherche à compiler l'exécutable "toto" à partir du fichier source "toto.c". Trois cas de figures possibles
                  1) "toto" l'exécutable n'existe pas encore. Make lance donc gcc comme spécifié.
                  2) "toto" existe. Make sort en répondant "Nothing to be done"
                  3) "toto" existe mais "toto.c" est plus récent que lui. Make estime donc que "toto" doit être mis à jour en conséquence et réappelle gcc.

                  Si en plus, "toto.c" est également une cible, alors ses propres dépendances vont être examinées récursivement, et tout ce qui doit être mis à jour derrière va l'être en cascade.

                  C'est donc utile pour les tout petits projets, car même avec un seul fichier, il est à la fois plus simple et plus sûr de taper "make" que de réappeler la commande entière depuis l'historique du shell, comme pour les plus gros car, quand on a une centaine de fichiers sources, on est sûr de ne recompiler que ce qui doit l'être. Quiquonque a déjà recompilé son noyau ou construit l'environnement GNOME, par exemple, à partir des sources voit bien de quoi je parle :-)

                  Bon, tout ceci forme le B-A-BA de Make, qui regorge d'options en tous genres pour faciliter le travail et factoriser ce qui peut l'être. Cibles implicites, génériques, variables du nom de cible, du compilo par défaut, des flags, etc.

                  Enfin, make sert principalement à gérer les dépendances entre fichiers. Il n'est pas intimement lié au C, ni même aux langages de programmation en général, même si c'est à cela qu'il est le plus utile.
              • [^] # Re: Répertoire courant

                Posté par  . Évalué à 2.

                et surtout, quand on fait "gcc test.c -o test", on a tendance à utiliser l'auto-complétion pour définir le nom de sortie, et il arrive toujours un moment ou l'on tape Entrée avant d'avoir tronqué l'extension. Et là, c'est "paf le fichier source".

                Juste en passant : ne serait-il pas relativement simple d'écrire un patch pour gcc détectant ce cas de figure et envoyant un avertissement dans la console (avant|au lieu) de blaster le source ?
  • # Merci

    Posté par  . Évalué à 2.

    Merci pour vos réponses, le début était simple mais la fin se complique !!

    Je ferais avec ./a.out cela fonctionne donc c'est parfait. Merci encore pour votre aide.a

Suivre le flux des commentaires

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