Forum Linux.général histoire de fou avec une commande

Posté par . Licence CC by-sa
Tags : aucun
3
12
nov.
2015

Bon j'ai un problème tordu et je suis largué après m'être bien pris la tête dessus :
J'ai une commande disons toto :
- si je fait which toto pour savoir ou elle se trouve j'obtiens par exemple /soft/blabla/toto.
- Si je tape "toto" dans mon terminal sa s'exécute visiblement sans erreur.
- maintenant si je tape /soft/blabla/toto j'ai "command not found"
- si je fais file /soft/blabla/toto j'ai ELF 32-bit LSB executable, … dynamically kinked…

Bon si quelqu'un a déjà eu ce problème je suis preneur. Merci

  • # developpeur ?

    Posté par . Évalué à 2.

    cas A :
    tu as un toto en local, un toto dans /soft/blablabla/toto
    c'est toto en local qui est executé

    cas B :
    tu n'as pas les droits x sur /soft/blablabla/toto

    • [^] # Re: developpeur ?

      Posté par . Évalué à 1.

      J'ai oublié de préciser que quand je tape toto, je me mets dans le répertoire
      /soft/blabla que j'ai trouvé avec la commande which, donc il s'agit bien du même executable.
      et su je fait ./lmhostid, j'ai aussi commande not found !

      donc que je tape toto ou /soft/blabla/toto ou ./toto, c'est bien le même executable dont il s'agit !

      Désolé j'aurais du préciser ça dès le début.

      • [^] # Re: developpeur ?

        Posté par (page perso) . Évalué à 2.

        J'ai oublié de préciser que quand je tape toto, je me mets dans le répertoire
        /soft/blabla que j'ai trouvé avec la commande which, donc il s'agit bien du même executable.

        Non, pas forcément. Pour forcer l'exécution de l'exécutable du répertoire courant, c'est ./toto et non toto tout court.

        Essai un "./toto" en te mettant dans le répertoire /soft/blabla.

        Vérifie également les droits d'exécution du fichier via "ls -lh /soft/blabla/toto".

        Enfin, afin de vérifier que c'est bien le bon exécutable, tu peux le renommer temporairement et voir si un simple "toto" s'exécute toujours. Si c'est le cas, c'est que c'est un autre exécutable qui est lancé et que la commande which est foireuse sur ce coup…

  • # Type

    Posté par . Évalué à 8.

    Salut,

    Si tu veux vraiment savoir quelle commande (ou fonction ou alias ou …) le shell va exécuter quand tu tapes "toto", la commande à utiliser est type toto
    En fait, which va t'indiquer où est le fichier exécutable toto mais il est possible que toto ne soit pas (seulement) un exécutable et which ne te l'indiquera pas.

    Note aussi que le fichier /soft/blabla/toto que tu indiques est un binaire 32 bits. Est-ce que ton système est aussi en 32 bits ou plutôt en 64 bits ? Il est possible que les librairies nécessaires à son exécution (en 32 bits aussi) n'existent pas sur ta machine et ça donne alors exactement le message d'erreur que tu obtiens. Quel est le résultat de la commande ldd /soft/blabla/toto ? S'il y a un "not found" quelque part, tu as ta réponse.

    A+
    JJD

    • [^] # Re: Type

      Posté par . Évalué à 2.

      j'ai aussi constaté cela avec un binaire 32 bits, sur une debian, alors que le "multi-arch" n'était pas activé et donc pas de libc 32 bits installée.

  • # Ldd

    Posté par (page perso) . Évalué à 2.

    Que donne ldd toto ?

    • [^] # Re: Ldd

      Posté par . Évalué à 0.

      J'avais déjà essayé, et tout est normal à ce niveau.

  • # je suppose l'utilisation de argv[0]

    Posté par . Évalué à 2.

    le programme test si il a été appelé par

    • plic, il fait plic
    • plac, il fait plac
    • plouc, il fait le plouc
    • sinon command not found

    comme /chemin/vers/plic != plic => command not found.

    As tu le même message si tu fais /bin/bidule
    et /soft/blabla/toto ?
    Est ce toujours le cas si tu change la langue ?
    LANG=C bash (ou LANG=fr_FR.UTF-8 bash )

    sinon les traditionnels strace/ltrace

    Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: je suppose l'utilisation de argv[0]

      Posté par . Évalué à 1.

      je ne suis pas certain d'avoir compris ce que tu veux dire par /chemin/vers/plic != plic => command not found
      car pour moi ça renvoie vers le même exécutable.
      Je ne connaissais pas strace et ltrace. Je n'ai plus d'accès à la machine avant lundi. J'essaie tout ça.
      Merci

      • [^] # Re: je suppose l'utilisation de argv[0]

        Posté par . Évalué à 2.

        car pour moi ça renvoie vers le même exécutable.

        non on s'est mal compris

        #include<stdio.h>
        int main(int argc, char* argv[])
        {
           printf("%s\n",argv[0]);
           return 1;
        }

        va afficher
        * toto si tu as appelé la commande via toto
        * ./toto si tu as appelé la commande via ./toto
        * /chemin/vers/toto si tu as appelé la commande via /chemin/vers/toto

        si tu as fait alias ploc=/tmp/toto puis $>ploc, cela affichera /tmp/toto, car c'est le shell qui s'occupe du remplacement
        si tu fais un lien symbolique ou non (ln -s /chemin/vers/toto tata )
        * ./tata affichera tata et ainsi de suite

        Je suppose que le programme teste le argv[0] via un strcmp, strncmp, strcasecmp ou strncasecmp, (d'où le ltrace/strace pour le repérer)

        Il me semble que la technique est utilisée par busybox pour réduire la place prise par le système; elle est aussi utilisée par les utilitaires versant (base de donnée orienté objet)

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

        • [^] # Re: je suppose l'utilisation de argv[0]

          Posté par . Évalué à 1.

          Merci pour ces précisions. Je suis démasqué, je suis une buse en programmation, mais ton petit exemple est très
          pédagogique.
          J'ai essayé strace (pour ltrace, j'ai command not found).
          j'ai pratiquement le même message, mais je ne suis pas trop capable d'interpreter.

          Le soucis c'est aussi que l'exécutable en question n'est pas libre, je n'ai pas les sources (et que même si je les avait…). Mon probleme est qu'en fait cet exécutable est appelé via in lien qui lui même est appelé par une interface graphique (en java je pense) et que c'est dans une espèce de console des log de cette interface que j'ai le message command not found. Et cette interface appelle cet exe via le chemin absolu complet, ce qui correspond manque de pot au cas qui ne marche pas. Je pense que c'est logique que l'interface utilise le chemin absolu, ça évite les pb par rapport à l'endroit d'ou on a lancé l'outil graphique.

          resultat de strace avec la commande complète (chemin absolu, cas ou j'ai commande not found) :

          strace /electronique/soft/IC615/tools.lnx86/bin/lmhostid
          execve("/electronique/soft/IC615/tools.lnx86/bin/lmhostid", ["/electronique/soft/IC615/tools.l"…], [/* 49 vars */]) = -1 ENOENT (No such file or directory)
          write(2, "strace: exec: No such file or di"…, 40strace: exec: No such file or directory
          ) = 40
          exit_group(1) = ?
          +++ exited with 1 +++

          maintenant le resultat avec la commande simple (cas qui marche) :

          strace lmhostid
          execve("/electronique/soft/IC615/tools.lnx86/bin/lmhostid", ["lmhostid"], [/* 49 vars */]) = -1 ENOENT (No such file or directory)
          write(2, "strace: exec: No such file or di"…, 40strace: exec: No such file or directory
          ) = 40
          exit_group(1) = ?
          +++ exited with 1 +++

          • [^] # Re: je suppose l'utilisation de argv[0]

            Posté par (page perso) . Évalué à 2.

            Aucun de tes deux exemple avec strace ne fonctionne. strace -f le shell et reproduit le problème (et le cas qui marche) depuis ce shell puis examine la différence.

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # trouvé

    Posté par . Évalué à 1.

    bon je me répond à moi même puisque j'ai trouvé :
    j'ai fait un :
    ln -s /lib/ld-linux.so.2 /lib/ld-linux.so.3

    depuis ca marche. JE ne comprends pas forcément pourquoi car normalement un pb de lib on le voit en faisant un ldd.

Suivre le flux des commentaires

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