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

Posté par gringonz le 12 novembre 2015 à 14:42. Licence CC By‑SA.

Étiquettes : aucune

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 NeoX le 12 novembre 2015 à 14:57. É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 gringonz le 12 novembre 2015 à 15:04. É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.
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 12 novembre 2015 à 15:19. Évalué à 2.
    
    Ce commentaire a été supprimé par l’équipe de modération.
    - [^] # Re: developpeur ?
      
      Posté par Romeo le 12 novembre 2015 à 17:04. Évalué à 4.
      
      ou un alias
# Type

Posté par JJD le 12 novembre 2015 à 15:49. É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 Marc Quinton le 13 novembre 2015 à 11:34. É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 JoeltheLion (site web personnel) le 12 novembre 2015 à 21:50. Évalué à 2.

Que donne ldd toto ?
- [^] # Re: Ldd
  
  Posté par gringonz le 13 novembre 2015 à 11:24. Évalué à 0.
  
  J'avais déjà essayé, et tout est normal à ce niveau.
# je suppose l'utilisation de argv[0]

Posté par fearan le 13 novembre 2015 à 15:19. É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 gringonz le 13 novembre 2015 à 15:58. É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 fearan le 13 novembre 2015 à 16:12. É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 gringonz le 13 novembre 2015 à 19:12. É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 Krunch (site web personnel) le 14 novembre 2015 à 10:16. É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 gringonz le 21 novembre 2015 à 16:09. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.