Bash – /usr/bin/ls: /usr/bin/ls: cannot execute binary file

bashshell

I'm using git bash on Windows. I want to run ls command with bash. I can run ls separately like this:

$ ls
f1  f2

However, when I try with bash, I get the error:

$ bash ls
/usr/bin/ls: /usr/bin/ls: cannot execute binary file

But if I create my script it works fine:

$ echo "echo \$@" > my.sh && bash my.sh

What can be the problem?

Best Answer

From the fine manual for bash(1):

ARGUMENTS If arguments remain after option processing, and neither the -c nor the -s option has been supplied, the first argument is assumed to be the name of a file containing shell commands.

Does ls contain shell commands? No, it is a binary file. bash squawks about this fact and fails.

A strace may help show what is going on:

$ strace -o alog bash ls
/usr/bin/ls: /usr/bin/ls: cannot execute binary file

The alog file can get a bit messy, but shows bash looking for ls in the current working directory—a security risk if someone has placed a naughty ls file somewhere!—and then does a PATH search:

$ grep ls alog
execve("/usr/bin/bash", ["bash", "ls"], [/* 43 vars */]) = 0
open("ls", O_RDONLY)                    = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/ls", 0x7fff349810f0) = -1 ENOENT (No such file or directory)
stat("/usr/bin/ls", {st_mode=S_IFREG|0755, st_size=117672, ...}) = 0
stat("/usr/bin/ls", {st_mode=S_IFREG|0755, st_size=117672, ...}) = 0
access("/usr/bin/ls", X_OK)             = 0
stat("/usr/bin/ls", {st_mode=S_IFREG|0755, st_size=117672, ...}) = 0
access("/usr/bin/ls", R_OK)             = 0
stat("/usr/bin/ls", {st_mode=S_IFREG|0755, st_size=117672, ...}) = 0
stat("/usr/bin/ls", {st_mode=S_IFREG|0755, st_size=117672, ...}) = 0
access("/usr/bin/ls", X_OK)             = 0
stat("/usr/bin/ls", {st_mode=S_IFREG|0755, st_size=117672, ...}) = 0
access("/usr/bin/ls", R_OK)             = 0
open("/usr/bin/ls", O_RDONLY)           = 3

As to why this could be a security risk, if you run bash somecmd from the wrong directory where someone has created a ls (or some other known command due to a bug in a script):

$ echo "echo rm -rf /" > ls
$ bash ls
rm -rf /
$

Related Solutions

Bash Error – Cannot Execute Binary File

The message cannot execute binary file has nothing to do with terminals (I wonder what led you to think that — and I recommend avoiding making such assumptions in a question, as they tend to drown your actual problem in a mess of red herrings). In fact, it's bash's way of expressing ENOEXEC (more commonly expressed as exec format error.

First, make sure you didn't accidentally try to run this executable as a script. If you wrote . ./executable, this tells bash to execute ./executable in the same environment as the calling script (as opposed to a separate process). That can't be done if the file is not a script.

Otherwise, this message means that ./executable is not in a format that the kernel recognizes. I don't have any definite guess as to what is happening though. If you can run the script on that same machine by invoking it in a different way, it can't just be a corrupt file or a file for the wrong architecture (it might be that, but there's more to it). I wonder if there could be a difference in the way the target boots (perhaps a race condition).

Here's a list of additional data that may help:

Output of file …/executable on server B.
Some information about the target, such as the output of uname -a if it's unix-like.
Check that the target sees the same file contents each time: run cksum ./executable or md5sum ./executable or whatever method you have on the target just before yet-another-bash-script invokes ./executable. Check that the results are the same in the Hudson invocation, in your successful manual invocation and on server B.
Add set -x at the top of yet-another-bash-script (just below the #!/bin/bash line). This will produce a trace of everything the script does. Compare the traces and report any difference or oddity.
Describe how the target is booting when you run the scripts manually and when Hudson is involved. It could be that the target is booted differently and some loadable module that provides the support for the format of ./executable doesn't get loaded (or is not loaded yet) in the Hudson invocations. You might want to use set -x in other scripts to help you there, and inspect the boot logs from the target.

Bash – automatically load shell scripts from /usr/bin

The alias you have defined will only take effect once the alias command is actually called. Thus if you were to do this:

$ source myscript
$ e "Hello"

It should work. However, this is clearly not ideal since you want e to be available whenever you start bash. Luckily, bash provides a number of ways to automatically run commands when the shell is started. For the full details of how bash starts up, see the manual page. For our purposes, it is enough to know that ~/.bashrc (that is, a file named ".bashrc" in your home directory) is run as your shell starts up. One way to make your alias available at startup would be to add this line at the end of ~/.bashrc:

source myscript

However, if you were to do this for every alias you wanted, your /usr/bin folder would likely become a mess. And, if you are on a multi-user system, filling /usr/bin/ with scripts like this may cause other users problems as well. Thus, it is better to place your aliases right inside .bashrc and forgo the separate script all together. Since you are using Ubuntu, inside your .bashrc file you probably have something that looks like this:

if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases 
fi

This code looks for a file call .bash_aliases in your home directory and runs anything it finds in that file as well. If you have this, or if you add this code to your .bashrc, you could also put your alias in ~/.bash_aliases. This provides an easy way to keep all your aliases in one place and keep your .bashrc file uncluttered.

Best Answer

Related Solutions

Bash Error – Cannot Execute Binary File

Bash – automatically load shell scripts from /usr/bin

Related Question