cygwin binary exec format error - linux

I have a script file that I was given to run in windows using Cygwin. When I try to use this file I get the following error
-bash: /sigdet/filename: cannot execute binary file: Exec format error.
sigdet is the folder within the Cygwin directory that I have the script. Rawdata is the name of the directory with the raw data files that the script is supposed to analyze.
To try and solve this, I have changed the file permissions, I have checked to make sure that it is on a 64 bit machine and the script appears to have compiled on a 64-bit machine. After these steps, I don't know what else the problem could be. Here are the commands I've entered:
I first changed the directory like so:
$ cd /sigdet/
Then I ran the script that is suppsed to work:
$ /sigdet/filename -i rawdata
Does the script file need to have an extension in windows? I've tried changing it to a .sh extension with no luck. I'm told that it just works on other windows machines just how it is.
Thanks to anyone that can help with this.

Your file is not an executable. It most probably contains ELF executable which is designed for Linux operating system, or it's corrupt.
If your file was a shell script, or in fact anything that contained plain text, you'd get different errors (such as, "expected command name" or "unknown command: XYZ" etc.)
Scripts are not supposed to have file extensions, like any executables. On the other hand, they should have shebangs: small text located in the first line that tells the system the path to the interpreter. For example, a Python executable script might be named whatever and have #!/usr/bin/python3 or similar in the first line. When you run it through ./whatever in the shell, it'll look for python3 in /usr/bin and run your file like this: /usr/bin/python3 ./whatever. (In fact, thanks to this you can also specify additional parameters that get passed to the interpreter.)
There is also a chance that your script is valid, but it contains a shebang pointing to bad interpreter. If that is the case, then most likely the path is correct, otherwise you'd get /whatever/interpreter: bad interpreter: no such file or directory error or similar. But then, all the other points apply to the interpreter (which is just another executable...)
If the script and/or interpreter was meant to be executed on Windows or Cygwin at least, it should either contain aforementioned shebang (#!/path in the first name) or it should be Windows executable (in which case the file data should begin with MZ letters, you can inspect it in notepad.) If it isn't, it means the files you were given can't run on Cygwin.

Had this same problem. Added the following at the top of makefile:
export ARCH = CYGNUS
What happened during the make process is that Linux and Windows versions of the executables were created. You just have to use ./.exe versions.

In my case, I got the error when I used a wrong command to compile my C program. When I used the right command:
gcc myprog.c -o myprog.exe
the error was resolved.

Related

jGRASP wedge: could not execute python3

I am trying to use jGrasp to run python3 for debugging purposes, but it is throwing the error below when I try to run my program I have downloaded python3 and I made sure it works in the terminal, but for some reason it is not working in jGrasp. It might have something to do with the PATH but I don't know what location I should add for jGrasp to be able to execute it properly.
The Python path should end with "bin", not "bin/python3". Paths need to be directories that contain executable files, not the executable files themselves. Whether you have added this path in jGRASP only, or at the OS level, you need to change it.

Run "./" bash/batch file with cygwin

Well the idea goes as followed,
I have a bash file for linux, there I obviously run it by making ./my_run.
The problem is I'm in windows so I downloaded and installed cygwin.
I added cygwin bin to the Enviromental Variables and check that at least "ls" works so I guessed I did it well.
When I try to run it with the cmd it displays:
'.' is not recognized as an internal or external command,
operable program or batch file.
As if the cygwin variables were not correctly installed (as I said I tried ls and works).
Then I tried it directly with cygwin and when doing the ./my_run I got it to work right.
So how is that I can use some commands like ls but when doing ./ it doesn't work on the cmd? How can I fix this?
Well, cygwin is only a shared library and a lot of stuff (the programs) using it (read Cygwin doc). cygwin.dll changes internally path resolution / chars to allow you to say ./my_script and converts it to .\my_script before doing the actual windows call, it also adds the proper extension to executables to allow it to execute windows binaries. This magic persists as long as you use it. cmd.exe is a Microsoft Windows command shell that is completely unaware of Cygwin's shared library and by that reason it doesn't use it, so it will not call it for path translation, even if you populate the environment of zetabytes of stuff. When you run in Cygwin terminal, you are running bash shell, which is a Cygwin executable, linked to cygwin.dll. It manages to use Cygwin library for all the unix system call emulations, so when you pass it e.g. to exec("./my_script", ...);, it internally converts that to try for ./my_script, then .\my_script, ./my_script.exe, ... and the same for .com and .bat extensions.
This fact often makes some people to say that Cygwin is not a good, efficient, environment. But the purpose was not to be efficient (and it is, as it caches entries and makes things best to be efficient) but to be compatible.
In your example ls is a Cygwin executable that mimics the /bin/ls executable from unix systems. It uses the Cygwin library, so all path resolution will be properly made (well, under some constraints, as you'll see after some testing) and everything will work fine. But you cannot pretend all your Windows applications to suddenly transform themselves and begin working as if they where in a different environment. This requires some try and error approach that you have to try yourself. And read Cygwin documentation, it is very good and covers everything I've said here.
If you open up Cygwin and run the command there you should be fine.

Linux executable on cygwin terminal [duplicate]

This question already has answers here:
Executable file generated using GCC under cygwin
(5 answers)
Closed 7 years ago.
Let me tell you my problem. I've a shell script which execute a Linux executable. I don't have access to the source code of this exe.
When I run the script on the Linux machine, there is no problem.
But, if I try to run the script on my Windows laptop, using cygwin, I have the error "cannot execute binary file".
There is any solution ?
Thanks !
From https://stackoverflow.com/a/4144536/5704102:
"... Cygwin is a compatibility layer, which aims to implement as much as possible of the POSIX and Linux APIs within Windows. This means that programs have to be compiled specifically for Cygwin ..."
What does this script look like? Is it a bash script? If so, you may want to try sh <scriptfile> in Cygwin. If this doesn't work, and it is a bash script, make sure you have sh.exe. Type sh and hit tab twice to check.
Another potential issue if it is a bash script is that you don't have something installed that Cygwin requires to run the script. Make sure all the commands the script is trying to run will work. If not, you may have to run the Cygwin installer and install whatever is needed to run the script.
Also, you may want to check permissions.
If the file has an exe extension, it SHOULD work on Windows unless it was compiled for 64 bit architecture and you're running a 32 bit OS. Otherwise, you could be missing some .dll files that the executable relies on.
Edit:
If this is the contents of your script:
echo START
/oper/file.exe
then it's likely you have the incorrect path. Cygwin paths typically start with /cygdrive/c/ in Windows. Go to where the file exists and type pwd to get the correct path, then modify your script accordingly.
Content of Script.sh in oper folder :
echo START
/cygdrive/c/Users/jo/oper/file.exe
In Cygwin terminal (in the right folder):
sh Script.sh
(Path updated)

Error "syntax error near unexpected token '&' - trying to run a file from command line within an application

I am a newbie to Linux and I am only really using it to use a program for my final year thesis. I have got to grips with the language for the program but am having issues with actually running it in Linux. The program is called "CACTUS" and all documentation can be found here.
I have extracted the application file and I have made the executable as instructed in the install.txt file:
"Installation of CACTUS for Linux or Mac machines.
Unzip the directory and put in desired location. On terminal cd into the
correct directory (you should be able to see the makefiles).
Create the executable by typing:
$make
or
$make -f Makefile.gfortran
on the terminal. The executable will be called cactus and be located in the
directory one level above.You can add the executable's location to your path
so that you can call it by simple typing cactus on the terminal instead of
the complete path.
cd into the Test/RegTest directory
$cd ./Test/RegTest
and run the RegTest by executing runreg.py with the path to the CACTUS
executable as an argument (or just the name of the executable if you added it
to your path).
$./runreg.py ../../../cactus
or
$./runreg.py cactus
The output should say 'No differences' for all three tests. Note: if you have
Python 3 installed used runreg_p3.py instead.
CONGRATULATIONS! You have successfully installed CACTUS.
I have run this and I didn't get the "No Differences" returned on the runreg.py. I continued anyway as I did not know why or how I could fix this. (This may be a root cause of my overally problem here)
As I progressed I have been trying to open an input file "TestVAWT.in" from TestCase2 with the following command:
./TestVAWT.in ../../../cactus
From this I get the error in the title returned. Am I correct in assuming that it has tried to run the TestVAWT.in file on the command line without referring to the Cactus application which I presume would be able to read the '&' prefix of the code along with the rest of the input file. Or is it something else I am missing here.
I would appreciate any help as I have been banging my head against a wall for some time now.
Note: I am using Ubuntu 14.04 LTS.
Best Regards
Richard
Don't know the application, but looks kind of strange to me.
Please try adding the Input-File as a parameter:
cactus TestVAWT.in

make: pwd: Command not found

I am new to using make files. I have cygwin and MinGW. I'm still looking into their differences.
Anyway, I have a makefile that is used to create a project for an FPGA, which I have never done before. I have included C:\cygwin\bin and C:\MinGW\msys\1.0\bin in my PATH, but I always get this error.
make: pwd: Command not found
I typed pwd into the cmd prompt and get a correct response. Any pointers? Am I missing something? Not sure what else I can try. Most forums I have found pertaining to this error never have a resolution.
Let me know what information you'd like.
pwd is commonly both a shell built-in command and a standalone executable, provided by GNU coreutils (which Cygwin installs by default).
If you're invoking make from the Cygwin environment (say, typing make at a bash shell prompt), then C:\cygwin\bin is the wrong way to specify the directory. That's the path as seen from Windows. From within Cygwin, it's /bin -- and it should be in your default $PATH. The Cygwin equivalent of C:\MinGW\msys\1.0\bin would be /cygdrive/c/mingw/msys/1.0/bin
If you're doing this directly from Windows rather than in the Cygwin subsystem, then C:\cygwin\bin is the path to the Cygwin bin directory -- but running C:\cygwin\bin\pwd is going to give you a Cygwin-specific directory name that's not going to be meaningful to Windows.
I have encountered the same issue in my mingw environment. It turned out in my case to be a missing 'pwd'executable in the msys/bin directory. Once the copying was done properly, everything fell into place. Hope this helps

Resources