[conspire] cannot execute binary file

[Michael Paoli]

> Date: Wed, 31 Aug 2016 17:37:11 +0000 (UTC)
> From: Paul Zander <paulz at ieee.org>
> To: Conspire List <conspire at linuxmafia.com>
> Subject: [conspire] cannot execute binary file
>
> This was buried in my earlier posting.? Having encountered the  
> problem at other times that appears to be related to PATH.
> I have a terminal window open to some directory.? Inside that  
> directory is a simple script.?? And PATH includes places like  
> /usr/bin, but not the current directory.
> Typing the following will usually run the script.
> ? .? ./myscript
> But for some more complex stuff, this doesn't always work.? For  
> example, I downloaded a Firefox tarball and unpacked it to some  
> directory.?? .? ./firefox
> ? bash: .: ./firefox: cannot execute binary file

Well, ... besides the detail that some character encodings might
be getting mangled - perhaps notably by list digest (ASCII is your friend),
at least from what I saw elsewhere on the thread, looks like the attempt
was something like:
$ . ./firefox
... but that's not what you'd want to do, as that attempts to source
the file - which will generally fail miserably for a binary executable.
Let's see if I can duplicate that type of behavior ...
$ type cp
cp is /bin/cp
$ file /bin/cp
/bin/cp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),  
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for  
GNU/Linux 2.6.32,  
BuildID[sha1]=17a96540d50955b258017a23ad57c7510ce2d9f8, stripped
$ cp -p /bin/cp .
$ . ./cp
bash: .: ./cp: cannot execute binary file
$
So ... I would hypothesize that's what you're trying to do - source a
binary file - and the failure you're getting, as I essentially  
reproduced above.

There was also a thread relatively recently on the SF-LUG list about
sourcing files ... vs. not (and changing shell's environment, etc.).

Anyway, in *most* cases, you don't want to be sourcing a file, but rather,
executing it.  If it's in your current directory, and current directory is
not on PATH (which should generally be the case, as having . or relative
directories on PATH is a security hazard), then one would typically execute
it via, e.g.:
$ ./program
So, in my above example, that would've been:
$ ./cp
And if we test that:
$ ./cp
./cp: missing file operand
Try './cp --help' for more information.
$
... it executes "fine" ... well, executes, and complains/"fails" as it should
as it was invoked, due to lack of mandatory arguments.  But it very much did
execute.

Also, as I show, file(1) is very handy for examining what it is you're
attempting to execute (or considering executing).  Also, if it's
interpreted language, rather than binary executable, read permission
also needs to be present (however lack of permission(s) would generally
give somewhat different diagnostics).