Executable is in current directory but can't be run [duplicate] - linux

Question

This question already has answers here:
Executing 32 bit code under Ubundu 64 bit installation error- No such file or directory
(3 answers)
Closed 7 years ago.
I'm having a weird problem where I have an executable in a directory, but when I try to run it, bash says that it doesn't exist:
kiarashsadr#pandoras-box:~/Downloads/Tether/linux$ ls
adb run.sh
kiarashsadr#pandoras-box:~/Downloads/Tether/linux$ ls -l
total 1204
-rwxrwxr-x 1 kiarashsadr kiarashsadr 1226659 Mar 9 2013 adb
-rwxrwxr-x 1 kiarashsadr kiarashsadr 521 Oct 29 2012 run.sh
kiarashsadr#pandoras-box:~/Downloads/Tether/linux$ ./adb
bash: ./adb: No such file or directory
output from file:
kiarashsadr#pandoras-box:~/Downloads/Tether/linux$ file adb
adb: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
wut??

Answer 1

You're trying to run a 32-bit executable on a 64-bit system. Bash doesn't differentiate between this case and "no such file or directory" case.
More about this topic: Executing 32 bit code under Ubundu 64 bit installation error- No such file or directory
More on how to run 32-bit executables on 64-bit systems: https://askubuntu.com/questions/454253/how-to-run-32-bit-app-in-ubuntu-64-bit

Answer 2

As stated by VOR73X, the reason in this case is that the file is a 32-bit executable on a 64-bit architecture. You can run it, but you need a compatibility layer to do so. If you have it:
mintaka:/home/lserni # file ansi
ansi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, not stripped
mintaka:/home/lserni # uname -a
Linux mintaka 4.0.1-1-default #1 SMP Wed Apr 29 15:04:53 UTC 2015 (e3a374a) x86_64 x86_64 x86_64 GNU/Linux
mintaka:/home/lserni # ./ansi
Syntax: ansi [file|-]
...and otherwise you get 'no such file or directory'.
However, there might be other reasons to be unable to run a file that "seems" to be there (or even is).
Missing dynamic libraries would give a distinctive error (at least they do on my system, Linux OpenSuSE 13.2):
./test: error while loading shared libraries: libcap.so.2: cannot open shared object file: No such file or directory
Another possibility...
...is that the file is not named as you think it is. The file you asked for is really not there!
For example (using the same obsolete file as before)
mintaka:/home/lserni # mv ansi 'ansi '
mintaka:/home/lserni # ls -la ansi*
-rwxr-xr-x 1 root root 14268 Sep 17 23:29 ansi
The file seems to be there but its name now ends with a space, so as you would expect...
mintaka:/home/lserni # ./ansi
bash: ./ansi: No such file or directory
Of course if the file is called correctly, escaping the space...
mintaka:/home/lserni # ./ansi\
Syntax: ansi [file|-]
mintaka:/home/lserni #
Other tricks are possible (I did it to myself once by mistake and have seen some worm using this trick to hide from a casual 'ls'). For example UTF8 invisible characters.
Try
ls -la | hexdump -C
to verify that the name is indeed what it ought to be.