Bash – Why does source give an error “cannot execute binary file”

bashshell

I have small file that does initialize a tmux session and then creates some windows. After some debugging and tweaking things worked fine until I renamed the text file (with the tmux commands) from spam to xset:

$ source xset
bash: source: /usr/bin/xset: cannot execute binary file

I have now renamed the file back and source spam works again, but I am wondering why this is. The file is in my home directory, and not in /usr/bin.

Best Answer

the bash internal command source, first looks for the filename in PATH, unless there is a slash (/) in the filename. xset is an executable file in your PATH, hence the problem.

You can either execute source ./xset or change the sourcepath option to off with:

shopt -u sourcepath

From the bash man-page:

      source filename [arguments]
          Read and execute commands from filename  in  the  current  shell
          environment  and return the exit status of the last command exe‐
          cuted from filename.  If filename does not contain a slash, file
          names  in  PATH  are used to find the directory containing file‐
          name.  The file searched for in PATH  need  not  be  executable.
          When  bash  is  not  in  posix  mode,  the  current directory is
          searched if no file is found in PATH.  If the sourcepath  option
          to  the  shopt  builtin  command  is turned off, the PATH is not
          searched.  If any arguments are supplied, they become the  posi‐
          tional  parameters  when  filename  is  executed.  Otherwise the
          positional parameters are unchanged.  The return status  is  the
          status  of  the  last  command exited within the script (0 if no
          commands are executed), and false if filename is  not  found  or
          cannot be read.

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 and Cron – Why Cron Ignores Variables Defined in .bashrc and .bash_profile

You can source the file you want at the top of the script or beginning of the job for the user that is executing the job. The "source" command is a built-in. You'd do the same thing if you made edits to those files to load the changes.

* * * * * source /home/user/.bash_profile; <command>

#!/bin/bash
source /home/user/.bash_profile

<commands>

Best Answer

Related Solutions

Bash Error – Cannot Execute Binary File

Bash and Cron – Why Cron Ignores Variables Defined in .bashrc and .bash_profile

Related Question