Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Bash : « Aucun fichier ou dossier de ce type » alors que le fichier existe.. .

35 réponses
Avatar
Francois Lafont
Bonjour à tous,

Je suis confronté à un problème bien mystérieux que je vous soumets et
qui pourrait se résumer à ceci :

#---------------------------------------------
# cd /etc/se3/bin/
# ls -l n*
-rwx------ 1 root root 999994 30 mai 13:19 numlock_active_i386
# ./numlock_active_i386
-bash: ./numlock_active_i386: Aucun fichier ou dossier de ce type
# ./n*
-bash: ./numlock_active_i386: Aucun fichier ou dossier de ce type
# test -e ./numlock_active_i386 && echo Existe
Existe
#---------------------------------------------

Comme vous pouvez voir, je suis root et le fichier numlock_active_i386
existe bel et bien (la complétion automatique du nom avec la touche TAB
fonctionne très bien) et les droits sont corrects. Au départ, je me
disais que, peut-être, le nom du fichier contenait je ne sais quel
caractère non imprimable ou un truc dans le genre, mais ça ne semble pas
être le cas :

#---------------------------------------------
# \ls n* | od -c
0000000 n u m l o c k _ a c t i v e _ i
0000020 3 8 6 \n
#---------------------------------------------

La partition qui contient le répertoire /etc/se3/bin/ est montée tout
simplement monté sur / et j'ai :

#---------------------------------------------
# mount | grep 'on / '
/dev/sda5 on / type ext4 (rw,errors=remount-ro)
#---------------------------------------------

Bref, au niveau de la partition je n'ai pas l'impression que ça soit
particulièrement exotique.

Autre information : la machine est une Debian Squeeze 64 bits.

#---------------------------------------------
# uname -a
Linux smm1-03 2.6.32-5-amd64 #1 SMP Sun May 6 04:00:17 UTC 2012 x86_64
GNU/Linux
#---------------------------------------------

Enfin, pour être parfaitement complet, il faut que je vous parle du
fichier en question (numlock_active_i386) car c'est un peu particulier.
Peut-être que ça n'a rien à voir avec le problème mais dans le doute je
vous livre ce qui suit. C'est peut-être important.

Le fichier numlock_active_i386 est en fait le résultat d'une compilation
d'un tout petit programme en langage C. En l'occurrence, ce programme là :

//------------------------------------------------
#include <X11/XKBlib.h>
#include <X11/extensions/XKB.h>
#include <X11/keysym.h>

int main () {
Display *disp = XOpenDisplay(NULL);
if(disp == NULL) return 1;
unsigned int nl_mask = XkbKeysymToModifiers(disp, XK_Num_Lock);
XkbLockModifiers(disp, XkbUseCoreKbd, nl_mask, nl_mask);
XCloseDisplay(disp);
return 0;
}
//------------------------------------------------

Ce programme (trouvé sur le Web car je suis nul en C) permet de simuler
l'appui sur la touche "VerrNum" afin d'activer le pavé numérique. Sur
Debian, il y a le paquet « numlockx » qui fournit la commande du même
nom qui fait exactement cela. Mais lorsque la commande numlockx est
lancée *avant* qu'un utilisateur ouvre une session, c'est-à-dire
typiquement au moment où la fenêtre de connexion du display manager
s'affiche, celle-ci ne fonctionne pas (il semble que ça soit un bug
connu et signalé à plusieurs reprises). C'est pourquoi, après des
recherches sur le Web, j'étais tombé sur le programme ci-dessus qui lui
fonctionne aussi au moment de l'affichage de la fenêtre de connexion.

Sur une Squeeze 32 bits, je l'avais compilé comme ceci, sans erreur
(auparavant il a fallu que j'installe le paquet « libx11-dev »)

$ gcc -l X11 numlock_active_i386.c -o numlock_active_i386

Mais le souci, c'est que j'obtenais un fichier qui ne marchait que sur
des 32 bits et au niveau des bibliothèques partagées (attention je suis
nul en C alors mes explications sont sans doute un peu foireuses) ça
coinçait quand je cherchait à lancer le binaire sur une 64 bits. Du
coup, j'ai *essayé* de faire une compilation qui encapsule toutes les
bibliothèques partagées nécessaires dans le binaire afin que celui-ci
soit « standalone » et qu'il marche aussi bien sur un 32 bits qu'un 64
bits.n Du coup, sur ma Squeeze 32 bits, j'ai fait ça :

$ gcc -l X11 -c numlock_active_i386.c -o numlock_active_i386.o

Ensuite, j'ai tenté ça :

gcc numlock_active_i386.o -o numlock_active_i386

Et en fonction des messages d'erreur un peu évocateur, j'ai ajouté des
bibliothèques jusqu'à que ceci me donne une compilation sans erreur :

gcc numlock_active_i386.o /usr/lib/libX11.a /usr/lib/libxcb.a \
/usr/lib/libXau.a /usr/lib/libXdmcp.a -o numlock_active_i386

Voilà, j'espère avoir donné toutes les informations nécessaires. Si ce
n'est pas le cas, n'hésitez pas à me demander.

Bref, pourquoi diable le shell me dit que le fichier n'existe pas alors
que celui-ci existe ?

Merci d'avance pour votre aide.



--
François Lafont

5 réponses

1 2 3 4
Avatar
Lucas Levrel
Le 30 mai 2012, Francois Lafont a écrit :

Perso, je m'attendais à trouver "i386" (qui pour moi veut « 32 bits »).



Pour moi, i386 veut dire « compatible PC 386 », i486 « compatible 486 »,
i586 « compatible Pentium », i686 « compatible Pentium Pro »
(http://fr.wikipedia.org/wiki/I686).

Sachant qu'il y a compatibilité seulement ascendante des processeurs, une
image i586 par exemple ne fonctionnera que sur des Pentia, pas sur des
80n86 avec n≤4.

--
LL
Avatar
Lucas Levrel
Le 31 mai 2012, Francois Lafont a écrit :

Les NOUVEAUX paquets suivants seront installés :
libpthread-stubs0 libpthread-stubs0-dev libx11-dev libxau-dev libxcb1-
dev libxdmcp-dev x11proto-core-dev x11proto-input-dev x11proto-kb-dev
xorg-sgml-doctools xtrans-dev



Concernant l'installation de ces paquts, il sont nécessaires :

1. seulement sur la machine où l'on fait la compilation ?
2. seulement sur la machine hôte qui exécutera le binaire ?
3. sur les deux machines ?



Les paquets -dev normalement sont pour les développeurs (toi en
l'occurrence !). Ils contiennent essentiellement les définitions des
fonctions se trouvant dans les bibliothèques (en C, les fichiers .h) et ne
sont nécessaires qu'à la compilation.

Pour les autres, tu peux toujours lister leur contenu pour voir.

--
LL
Avatar
Arnaud Gomes-do-Vale
Lucas Levrel writes:

Pour moi, i386 veut dire « compatible PC 386 », i486 « compatible
486 », i586 « compatible Pentium », i686 « compatible Pentium Pro »
(http://fr.wikipedia.org/wiki/I686).

Sachant qu'il y a compatibilité seulement ascendante des processeurs,
une image i586 par exemple ne fonctionnera que sur des Pentia, pas sur
des 80n86 avec n≤4.



Ça c'est la théorie, en pratique je doute qu'une distribution récente
fonctionne sur quoi que ce soit de plus vieux qu'un Pentium Pro ou un
Pentium II.

Mais pour revenir un peu vers la question de départ, c'est vrai que
c'est assez pénible de ne pas avoir de moyen simple (je veux dire, à
part une expression rationnelle du genre i[3-6]86) de reconnaitre un
«ia32 ou assimilé».

--
Arnaud
http://blogs.glou.org/arnaud/
Avatar
Francois Lafont
Bonjour,

Le 31/05/2012 16:04, Lucas Levrel a écrit :

Les NOUVEAUX paquets suivants seront installés :
libpthread-stubs0 libpthread-stubs0-dev libx11-dev libxau-dev libxcb1-
dev libxdmcp-dev x11proto-core-dev x11proto-input-dev x11proto-kb-dev
xorg-sgml-doctools xtrans-dev



Concernant l'installation de ces paquts, il sont nécessaires :

1. seulement sur la machine où l'on fait la compilation ?
2. seulement sur la machine hôte qui exécutera le binaire ?
3. sur les deux machines ?



Les paquets -dev normalement sont pour les développeurs (toi en
l'occurrence !). Ils contiennent essentiellement les définitions des
fonctions se trouvant dans les bibliothèques (en C, les fichiers .h) et
ne sont nécessaires qu'à la compilation.



Oui, ça bien bien clair pour moi. Au passage, le seul paquet que j'avais
pris la peine d'installer sur la machine où j'ai compilé c'est
libx11-dev car sans lui j'avais plein d'erreurs à la compilation.
Ensuite plus d'erreur. Du coup, j''imagine que si un fichier *.h avait
manqué, le compilateur me l'aurait fait remarquer immédiatement.

Pour les autres, tu peux toujours lister leur contenu pour voir.



Ça n'a pas été très éclairant pour moi. Le paquet libpthread-stubs0 est
une dépendance (par ricochets) du paquet libx11-dev dont si
libpthread-stubs0 est nécessaire uniquement sur la machine où l'on
compile, le problème est réglé. Maintenant, je n'ai pas compris si
c'était le cas.

Pour le paquet xorg-sgml-doctools, je suis perplexe :

« This package contains tools for building the X.Org SGML documentation.
Currently it only includes various entity definitions for the current
release. »

C'est une histoire de documentation apparemment... Je ne pense pas que
ça soit indispensable mais je me trompe peut-être.

Par ailleurs, je pense avoir mal compris les indications de « moi-même »
car quand il a donné la commande de compilation « gcc numlockx.c -lX11
-o /usr/bin/numlockx », j'ai cru que numlockx.c correspondait au source
du binaire numlockx issu du paquet debian officiel de même nom. Mais en
fait, il s'agit, j'imagine, du petit source donné en premier message,
auquel cas je suis surpris qu'on mette le binaire dans /usr/bin/numlockx
qui correspond à l'emplacement de la commande numlockx « officielle » de
Debian.


--
François Lafont
Avatar
Nicolas George
Arnaud Gomes-do-Vale , dans le message
, a écrit :
Mais pour revenir un peu vers la question de départ, c'est vrai que
c'est assez pénible de ne pas avoir de moyen simple (je veux dire, à
part une expression rationnelle du genre i[3-6]86) de reconnaitre un
«ia32 ou assimilé».



Il faudrait commencer par définir rigoureusement ce que ça veut dire.
1 2 3 4