Bash says file does not exist, but it does

I'm trying to compile the firmware for my linksys WRVS4400N.

ls shows that exist but when it try to run it bash says it does not exist. I can also cat it, and it is an executable, not a shell script.

4 Answers

You mentioned that the output of file mkdep is 32-bit elf. You're running a 64-bit VM.

Example:

$ uname -m x86_64 $ ls -l ./example -rwxr-xr-x 1 root root 92312 2011-08-18 16:52 ./example $ file ./example example: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped $ ./example -bash: ./example: No such file or directory 

Just make a new 32-bit VM and compile it there.

Is it set to being executable? If not, then chmod +x filename. Is it in your PATH? If not, then call it as ./filename rather than just filename.

When you try to execute a file and bash says it doesn't exist it sometimes means that bash believes the file is a script and that the interpreter specified in the first line (#!) does not exist.

If the files is named mkdep I would post the output of

./mkdep file mkdep hd mkdep | head strace ./mkdep 2>mkdep.strace.txt 

The strace command give info about system calls made, for example strace ls 2>ls.t puts the following into ls.t

 execve("/bin/ls", ["ls"], [/* 22 vars */]) = 0 brk(0) = 0x8061000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f82000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=32311, ...}) = 0 mmap2(NULL, 32311, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f7a000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/librt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\30\0\0004\0\0\0"..., 512) =512 fstat64(3, {st_mode=S_IFREG|0644, st_size=30624, ...}) = 0 

Are you changing IFS in your script? I too encountered the same problem in one of my scripts and thought the same (32 bit file being read by shell script on 64 bit machine). But that wasn't the issue in my case. Instead, I was changing IFS to comma ',' and back to new line which somehow confused the parser and caused this error.

I just removed any change in IFS and it works just fine now!!!