Cannot execute binary file exec format error cygwin

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.

I have a problem where I can’t do my vagrant up in cygwin, because cygwin can’t understand non-POSIX style paths like C:, which the vagrantfile uses.

I use git-bash to start vagrant, because it can understand the non-POSIX paths. To make my life even simpler, I created windows .lnk files to launch bash scripts in git-bash that start my ssh agent and start vagrant.

I wanted it to take a step further and use bash aliases in cygwin to create an alias for vagrant up that would launch my vagrant-up.lnk, etc, which in turn would launch a git-bash session and finally start my vagrant instance.

However, I am having a strange problem where I cannot launch .lnk files with cygwin nor git-bash.

~/Desktop
$ cygstart vagrant-up.lnk
Unable to start 'vagrant-up.lnk': The specified path was not found.

Thinking it was a path issue, I tried giving the full path:

~/Desktop
$ cygstart -o /cygdrive/c/Documents and Settings/user/Desktop/vagrant-up.lnk
Unable to start 'C:Documents and SettingsuserDesktopvagrant-up.lnk': The operating system denied access to the specified file.

The error message seems more useful in git-bash

MINGW64 /c/Users/user/Desktop
$ ./vagrant-up.lnk
bash: ./vagrant-up.lnk: cannot execute binary file: Exec format error

I googled the «bash cannot execute binary file» error, but only found results about *nix utilities compiled for the wrong architecture (e.g. AIX on x86, etc)

On Timothy Martin’s suggestion, I also tried this, to no avail:

$ cygstart /cygdrive/c/Users/user/Desktop/vagrant-up.lnk
Unable to start 'C:UsersuserDesktopvagrant-up.lnk': The specified path was not found.

It is interesting that it uses windows-style paths in this error message, but I don’t know how to turn that fact into a resolution of my problem.

In the vagrant-up.lnk, the Target: is
"C:Program FilesGitgit-bash.exe" -l "C:cygwinhomeuservagrantscriptsvagrant-up.git-bash" and Start in: is in "C:Program FilesGit".

What do I need to do to launch these .lnk files from cygwin? They run just fine when I double-click them in Windows.

How to Fix ‘cannot execute binary file: Exec format error’ on Ubuntu

While it shouldn’t happen when using the official apt-get repositories, if you download software off the Internet and run it then there’s a chance that you’ll see the dreaded bash: ./nameOfProgram: cannot execute binary file: Exec format error. This error, which is usually followed by bash: ./nameOfProgram.sh: Permission denied or something like it, indicates that Ubuntu wasn’t able to interface correctly with the binary you downloaded. This is because while it’s apparently a valid Linux binary, it’s designed for a different chipset than your kernel currently supports.

Most people using Ubuntu are on 32-bit or 64-bit processors based around a standard architecture that Intel released, regardless of who actually made their microchips. It’s important to remember that 64-bit processors can run in 32-bit mode, so if you’re getting this error even though you have a 64-bit processor there’s a chance you’re running a 32-bit version of Ubuntu. A few simple commands are all it takes to tell what your chip is operating as.

Method 1: Using the arch Command

If you’re not familiar with the type of microprocessor that you have installed on your machine, then you’ll first want to use the arch command from the command line. You’ll only see a single line of output returned to you after running this command. In many cases, you’ll see i686, which means that you’re on a 32-bit processor and therefore can’t run x86_64 binaries. If you instead see amd64 or something similar, then you’re on an x86_64 processor, and should at least theoretically be able to run most 32-bit and 64-bit binaries. Unlike Microsoft Windows, Ubuntu Linux actually contains the proper tools to permit users of 644-bit chipsets to run 16-bit Windows programs in their operating system in many cases as well.

These terms are still true even if you’re not actually using that particular model of microchip. For instance, i686 is how Linux refers to many 32-bit processors even if they aren’t actually Intel 80686 chips. Even if you’re using 64-bit Intel technology, arch might still call your processor an amd64 chip. This doesn’t indicate an error, and can be safely ignored. You can use cat /proc/cpuinfo or more /proc/cpuinfo to find out the exact type of processor you’re using. Since the lines in this file are long, you might want to push F11 before issuing it if you’re using a graphical terminal window. Users of a virtual console, especially those working with Ubuntu server, won’t have to worry quite as much.

You may see some other types of output, which might further restrict your options when it comes to running software. Ubuntu supported PowerPC architecture for the longest time, which is found in some workstations as well as many Classic Macintosh and older OS X Macintosh machines. You can actually still find Ubuntu repositories for these architectures, though they receive little support today. However, you more than likely won’t be able to run many Linux binaries you download from the Internet outside of the official repositories in this case. That doesn’t mean that Ubuntu doesn’t work on these machines, though you may want to look at the lighter Lubuntu distribution.

Method 2: Using the file Command

The file command identifies what different files contain, and it’s usually very accurate. Try identifying the file in question by typing file nameOfProgram to see if you get ELF 32-bit or ELF 64-bit as output. If it tells you that it’s an ELF 64-bit binary and you received i686 as output from the arch command, then there’s no way you can reasonably run it on your machine. If you’re on a 64-bit microprocessor running 32-bit Ubuntu, then you could technically reinstall the operating system, though this is a bit of an extreme step in order to run a single program.

There is also the very real possibility, however slight, that you might instead come across a binary that when you attempt to run it spews out junk characters to the terminal even if you’ve run a malware scan on it. These characters usually take the form of either lozenge-shaped blocks, or alternatively rectangular cubes that have numerical values in them. Some computer scientists call the latter tofu, and represent the Unicode values of characters that your currently installed typefaces won’t be able to display. If the terminal is displaying them like this, then you can rest assured that this is neither a font error nor anything having to do with malware. Rather, this is simply because the compiled microprocessor opcode inside of the binary is so alien to your system that it doesn’t know how to interpret some of the code.

The best way to fix this is to install the proper package for your architecture. If you’re installing packages from inside Ubuntu, then the apt-get system or the graphical Synaptic manager has you covered without any problems. If you’re downloading packages from another distribution, then you’ll need to find the right one for your architecture. Take, for example, Arch Linux’s listing of the gvim package. While the default package features the x86_64 architecture, there’s also one for the i686 chipset. This one will work on 32-bit machines that work with the Intel interrupt structure, but remember that the terms i686 and 32-bit are not mutually inclusive all the time since other chipsets Linux supports actually do feature their own 32-bit implementations.

Users exploring the whole GNU/Linux scene might come across binaries compiled for far more exotic technologies than these. Linux is truly a cross-platform code scene, so you’ll see OpenRISC, MIPS, SPARC, M32R, MN103, ARM, ARC, Alpha and many other standards binaries are compiled to work with. More than likely, you won’t be able to run any of these, though ARM is an extremely popular tablet and smartphone platform. It’s also the platform that the Raspberry Pi is based around, which means if you’re actually running Ubuntu on a mobile device or the Ubuntu MATE distribution for Raspberry Pi you’ll actually need these instead of Intel 32-bit or x86_64 binaries.

Источник

Решение проблемы с ошибкой «bash: не удаётся запустить бинарный файл: Ошибка формата выполняемого файла»

В операционной системе Linux при запуске скаченного файла, либо при запуске самостоятельно скомпилированного файла вы можете столкнуться с ошибкой:

Если у вас англоязычная локаль, то ошибка будет примерно такой:

bash: ./program: cannot execute binary file: Exec format error

В самой ошибке вместо /путь/до/файла и ./program будет указан путь до файла программы, который вы хотите запустить.

• Причинами данной ошибки могут быть:
• попытка запустить 64-битный файл на 32-битной системе
• файл скомпилирован для другой архитектуры (например, для ARM, а вы пытаетесь запустить его на ПК)
• вы пытаетесь выполнить не исполнимый файл, а ссылку
• файл размещён в совместной (shared) папке

Чтобы получить информацию о файле, который вы пытаетесь запустить, можно использовать утилиту file, после которой укажите путь до файла:

Здесь мы видим, что файл предназначен для 64-битной системы, об этом говорит запись 64-bit, для процессора с архитектурой x86-64.

Ещё один пример:

Этот файл для 32-битных систем, для процессора с архитектурой ARM EABI4.

Если вы не знаете, какой битности ваша система, то выполните команду:

Для 64-битных систем будет выведено x86_64, а для 32-битных – x86.

О разрядности дистрибутивов Linux и о программ

На компьютер с 32-битным процессором вы можете установить только 32-битную операционную систему и в ней запускать только 32-битные программы.

На компьютер с 64-битным процессором вы можете установить как 64-битную ОС, так и 32-битный Linux. В случае, если вы установили 64-битный дистрибутив Linux, то в нём вы можете запускать и 64-битные программы и 32-битные. А если вы установили 32-битный дистрибутив, то в нём возможно запускать только 32-битные программы.

Итак, если у вас 32-битная система, а файл для 64-битной системы или даже для ARM архитектуры, то у вас следующие варианты:

• скачать файл подходящей для вас битности и архитектуры
• если вы самостоятельно компилировали файл из исходного кода, то заново скомпилируйте для процессора вашей архитектуры

Запуск ARM файлов в Linux

Часто можно запустить исполнимые образы ARM на amd64 системах если установить пакеты binfmt-support, qemu, и qemu-user-static:

sudo apt install binfmt-support qemu qemu-user-static

Заключение

Итак, ошибка формата выполняемого файла с невозможностью запустить бинарный файл возникает из-за несоответствия программы операционной системе или архитектуре процессора. Эта проблема не должна возникать, если вы установили программу из исходных репозиториев (кроме случаев неправильной настройки источников репозитория). При возникновении этой проблемы поищите файл, подходящий для вашей архитектуры или скомпилируйте файл из исходных кодов под архитектуру вашей операционной системы.

Источник

🛠️ Исправление ошибки «Exec format» при запуске скриптов командой run-parts

Решение ошибки «Exec format» при запуске скриптов командой run-parts

Чтобы запустить все скрипты в папке «Documents», я запустил:

Я получил следующее сообщение об ошибке:

Bourne shell, или совместимый шеллl:

Bash:

Perl:

Python 2.x:

Python 3.x:

Это то, что мы называем шебанг.

Теперь вернемся к теме.

Отредактируйте ваши скрипты, используя ваш любимый редактор:

Добавьте шебанг в начале скрипта:

Теперь вы можете без проблем запускать скрипты с помощью команды run-parts, используя команду run-parts.

Вы также можете использовать утилиту ShellCheck для поиска проблем в своих скриптах оболочки.

• Аудит ИБ (49)
• Вакансии (12)
• Закрытие уязвимостей (105)
• Книги (27)
• Мануал (2 234)
• Медиа (66)
• Мероприятия (39)
• Мошенники (23)
• Обзоры (800)
• Обход запретов (34)
• Опросы (3)
• Скрипты (109)
• Статьи (336)
• Философия (99)
• Юмор (18)

Anything in here will be replaced on browsers that support the canvas element

Источник

How to fix Cannot execute binary file: exec format error?

Photo by Jivacore/Shutterstock.com

Linux has been reworked heavily since it first came out to the point that it’s no longer an OS for terminal kings. Just about everyone can use it now thanks to the much better user interfaces that we see in modern Linux distros. However, that doesn’t mean it can’t be frustrating at times.

In this article, we’re taking a look at the “cannot execute binary file: exec format error” issue and giving you a few solutions on how to get rid of the problem.

Check the architecture

The first thing you should do is ensure you’ve got the right bin file. Binary files made for 32-bit systems won’t work on 64-bit systems and vice-versa. You can check the architecture of any file by using the command below.

If the architecture doesn’t match between your file and the PC you’re running it on, try running the corresponding binary file for the matching architecture.

Check the file

Binary files can be run on Windows, Linux and macOS. However, binaries made for one OS won’t run on the others. Generally, these files have different file formats to help users distinguish between them. If you’re trying to run a binary file made for Windows on a Linux distro, it’s obviously not going to work.

If you must run the binary on Linux however, we recommend downloading Wine and using it to run the file. Wine is a compatibility layer capable of running Windows applications on POSIX-compliant operating systems, including Linux and macOS.

Install GCC and Gfortran

GCC and Gfortran are required for several binary files to compile and execute properly. You can install them by typing the command below in your terminal.

Now try running your binary file again and it should run without a problem — fixing the ‘cannot execute binary file’ error.

Uncompress the file

Sometimes binary files are compressed to make them easier to share over the internet. Try uncompressing the file to see if that helps you run it fine. Run the following commands on at a time.

Check file permissions

Another potential reason for your binary file not running could be that the user doesn’t have permission to change or read the file. You can fix this by typing the following command in the terminal.

Once the permissions are set, you can run the file by typing this.

Use Dos2unix

The Dos2unix command can sometimes help binaries made for DOS to run on UNIX systems. Try using the following command to see if your file runs or not.

If we’ve missed out on any fixes that helped you solve the ‘cannot execute binary file’ error, please comment down below with the fix.

Someone who writes/edits/shoots/hosts all things tech and when he’s not, streams himself racing virtual cars.

You can contact him here: [email protected]

Источник

Photo by Jivacore/Shutterstock.com

Linux has been reworked heavily since it first came out to the point that it’s no longer an OS for terminal kings. Just about everyone can use it now thanks to the much better user interfaces that we see in modern Linux distros. However, that doesn’t mean it can’t be frustrating at times. 

In this article, we’re taking a look at the “cannot execute binary file: exec format error” issue and giving you a few solutions on how to get rid of the problem. 

Also read: How to make a file executable in Linux?

Check the architecture

The first thing you should do is ensure you’ve got the right bin file. Binary files made for 32-bit systems won’t work on 64-bit systems and vice-versa. You can check the architecture of any file by using the command below.

file filename

If the architecture doesn’t match between your file and the PC you’re running it on, try running the corresponding binary file for the matching architecture. 

Check the file

Binary files can be run on Windows, Linux and macOS. However, binaries made for one OS won’t run on the others. Generally, these files have different file formats to help users distinguish between them. If you’re trying to run a binary file made for Windows on a Linux distro, it’s obviously not going to work. 

If you must run the binary on Linux however, we recommend downloading Wine and using it to run the file. Wine is a compatibility layer capable of running Windows applications on POSIX-compliant operating systems, including Linux and macOS. 

Install GCC and Gfortran

GCC and Gfortran are required for several binary files to compile and execute properly. You can install them by typing the command below in your terminal. 

sudo apt-get install gfortran && sudo apt-get install build-essential

Now try running your binary file again and it should run without a problem — fixing the ‘cannot execute binary file’ error.

Uncompress the file

Sometimes binary files are compressed to make them easier to share over the internet. Try uncompressing the file to see if that helps you run it fine. Run the following commands on at a time. 

xz -d ./filename
chmod +x ./filename
./filename

Check file permissions

Another potential reason for your binary file not running could be that the user doesn’t have permission to change or read the file. You can fix this by typing the following command in the terminal. 

chmod +x filename

Once the permissions are set, you can run the file by typing this.

./filename

Use Dos2unix

The Dos2unix command can sometimes help binaries made for DOS to run on UNIX systems. Try using the following command to see if your file runs or not. 

dos2unix filename.bin

If we’ve missed out on any fixes that helped you solve the ‘cannot execute binary file’ error, please comment down below with the fix.

Also read: What does ./ mean in Linux?

Hi guys,

Thanks a lot for the responses!

My OP was from 08 July 2019; at that time, /var/log/pacman.log says I’ve had:

[2019-07-08 10:04] [ALPM] installed mingw-w64-x86_64-python3-jupyter_client (5.2.4-1)

Some days ago, I noticed something was updated for jupyter — checking again through /var/log/pacman.log I can see only this:

[2019-07-23 09:03] [ALPM] upgraded mingw-w64-x86_64-python3-jupyter_client (5.2.4-1 -> 5.3.1-1)

So, I decided to try it again; again, first with MINGW64, fails:

user@PC MINGW64 ~
$ jupyter notebook
bash: /mingw64/bin/jupyter: cannot execute binary file: Exec format error

user@PC MINGW64 ~
$ which jupyter
/mingw64/bin/jupyter

user@PC MINGW64 ~
$ file /mingw64/bin/jupyter
/mingw64/bin/jupyter: MS-DOS executable

So, I thought — hey, if it complains about «MS-DOS», and it doesn’t run in MSYS2 — maybe it will run in MINGW32? And yeah, it does:

user@PC MINGW32 /c/bin
$ jupyter notebook
[W 08:38:30.200 NotebookApp] Terminals not available (error was No module named 'winpty')
[I 08:38:30.215 NotebookApp] Serving notebooks from local directory: C:/bin
[I 08:38:30.215 NotebookApp] The Jupyter Notebook is running at:
[I 08:38:30.215 NotebookApp] http://localhost:8888/?token=9d64d0212e47a1658c99e4b612dc4d2d312eddabae03593c
[I 08:38:30.215 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[C 08:38:30.246 NotebookApp]

    Copy/paste this URL into your browser when you connect for the first time,
    to login with a token:
        http://localhost:8888/?token=9d64d0212e47a1658c99e4b612dc4d2d312eddabae03593c
[I 08:38:30.684 NotebookApp] Accepting one-time-token-authenticated connection from ::1

… although, when you open a new Python 3 notebook, it starts a kernel, but then it is just stuck on «Connecting to kernel».

Not sure if this latest jupyter_client had anything to do with this (nor am I sure on, how and why would a mingw-w64-x86_64* package have an influence on something not running in MINGW64, but running in MINGW32 ?!) But that is what I can see…

Btw, i got worried about Terminals not available (error was No module named 'winpty'), and so I tried this:

user@PC MINGW32 ~
$ pacman -S winpty
warning: winpty-0.4.3-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (1) winpty-0.4.3-1

Total Installed Size:  3.17 MiB
Net Upgrade Size:      0.00 MiB

:: Proceed with installation? [Y/n] y
...

That, unfortunately, did not solve the issue with No module named 'winpty' — so went to the Python side of things:

user@PC MINGW32 ~
$ pip3 install --upgrade pip
Collecting pip
  Downloading https://files.pythonhosted.org/packages/62/ca/94d32a6516ed197a491d17d46595ce58a83cbb2fca280414e57cd86b84dc/pip-19.2.1-py2.py3-none-any.whl (1.4MB)
     |████████████████████████████████| 1.4MB 2.3MB/s
Installing collected packages: pip
  Found existing installation: pip 19.1.1
    Uninstalling pip-19.1.1:
      Successfully uninstalled pip-19.1.1
Successfully installed pip-19.2.1

user@PC MINGW32 ~
$ pip3 install winpty
Collecting winpty
  ERROR: Could not find a version that satisfies the requirement winpty (from versions: none)
ERROR: No matching distribution found for winpty

user@PC MINGW32 ~
$ pip3 search winpty
pywinpty (0.5.5)             - Python bindings for the winpty library
yawinpty (0.4.3)             - yet another winpty binding for python
yawinpty-extra (0.1.0.dev1)  - yet another winpty binding for python (extra
                               package)

user@PC MINGW32 ~
$ pip3 install pywinpty
Collecting pywinpty
  Downloading https://files.pythonhosted.org/packages/21/ae/acbedcee475d049647e45ee949e23ca492764fcd8027a073fcf07646d47c/pywinpty-0.5.5.tar.gz (48kB)
     |████████████████████████████████| 51kB 1.2MB/s
Installing collected packages: pywinpty
  Running setup.py install for pywinpty ... done
Successfully installed pywinpty-0.5.5

This did not solve the No module named 'winpty' either — and the reason is this:

user@PC MINGW32 ~
$ python3
Python 3.7.4 (default, Jul 11 2019, 09:35:14)
[GCC 9.1.0] on msys
Type "help", "copyright", "credits" or "license" for more information.
>>> import winpty
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/site-packages/winpty/__init__.py", line 11, in <module>
    from .ptyprocess import PtyProcess
  File "/usr/lib/python3.7/site-packages/winpty/ptyprocess.py", line 21, in <module>
    from .winpty_wrapper import PTY, PY2
  File "/usr/lib/python3.7/site-packages/winpty/winpty_wrapper.py", line 7, in <module>
    from ctypes import windll
ImportError: cannot import name 'windll' from 'ctypes' (/usr/lib/python3.7/ctypes/__init__.py)
>>>

So, I guess I «just» need to find and install ctypes.windll for this Python, and maybe Jupyter will start working?! I’ll try to do some more testing when I have time, and I’ll report back if I manage to get forward …

EDIT: Just wanted to say I found this, from 2013: Windows build (ghc-devs):

msys2-compiled python is cygwin-like and it’s ‘ctypes’ has no ‘windll’.

… although, I found also this from 2013, which implies otherwise: Building a DLL with MinGW and loading it with Python’s ctypes module — Stack Overflow:

I can ctypes.windll.loadlibrary(…) an ordinary windows DLL found in the windows/system32 without an issue.