Question or issue on macOS:
I know it, forget it and relearn it again. Time to write it down.
How to solve this problem?
Solution no. 1:
To run a non-executable sh script, use:
The file you linked can be opened, for proper display, in LibreOffice, which by the way is free. I was also able to convert this file via the command line to a plain text document using LibreOffice's executable soffice using the following syntax. File Converter; Free File Editor; Free File Viewer; Free File Merger; Free File Splitter; Free File Comparison; Free File Metadata Editor; SEO Tools. Our All Free SEO Tools (80+ tools) Free Article Rewriter Pro; Free Plagiarism Checker Pro; Free Premium Backlink Maker; Free Complete Website Reviewer; Free Moz Bulk Domain Authority Checker Pro. Posted: (5 days ago) Sep 16, 2008 a unix executable file is just that, a file that's executable (like a windows.exe file). While Mac OS is UNIX, the file you have, if it isn't part of a Mac program, may not run on your system because: 1. It may be compiled to run on a different type CPU 2.
To run a non-executable bash script, use:
To start an executable (which is any file with executable permission); you just specify it by its path:
To make a script executable, give it the necessary permission:
When a file is executable, the kernel is responsible for figuring out how to execte it. For non-binaries, this is done by looking at the first line of the file. It should contain a hashbang:
The hashbang tells the kernel what program to run (in this case the command /usr/bin/env is ran with the argument bash). Then, the script is passed to the program (as second argument) along with all the arguments you gave the script as subsequent arguments.
That means every script that is executable should have a hashbang. If it doesn’t, you’re not telling the kernel what it is, and therefore the kernel doesn’t know what program to use to interprete it. It could be bash, perl, python, sh, or something else. (In reality, the kernel will often use the user’s default shell to interprete the file, which is very dangerous because it might not be the right interpreter at all or it might be able to parse some of it but with subtle behavioural differences such as is the case between sh and bash).
A note on /usr/bin/env
Most commonly, you’ll see hash bangs like so:
The result is that the kernel will run the program /bin/bash to interpret the script. Unfortunately, bash is not always shipped by default, and it is not always available in /bin. While on Linux machines it usually is, there are a range of other POSIX machines where bash ships in various locations, such as /usr/xpg/bin/bash or /usr/local/bin/bash.
To write a portable bash script, we can therefore not rely on hard-coding the location of the bash program. POSIX already has a mechanism for dealing with that: PATH. The idea is that you install your programs in one of the directories that are in PATH and the system should be able to find your program when you want to run it by name.
Sadly, you cannot just do this:
The kernel won’t (some might) do a PATH search for you. There is a program that can do a PATH search for you, though, it’s called env. Luckily, nearly all systems have an env program installed in /usr/bin. So we start env using a hardcoded path, which then does a PATH search for bash and runs it so that it can interpret your script:
This approach has one downside: According to POSIX, the hashbang can have one argument. In this case, we use bash as the argument to the env program. That means we have no space left to pass arguments to bash. So there’s no way to convert something like #!/bin/bash -exu to this scheme. You’ll have to put set -exu after the hashbang instead.
This approach also has another advantage: Some systems may ship with a /bin/bash, but the user may not like it, may find it’s buggy or outdated, and may have installed his own bash somewhere else. This is often the case on OS X (Macs) where Apple ships an outdated /bin/bash and users install an up-to-date /usr/local/bin/bash using something like Homebrew. When you use the env approach which does a PATH search, you take the user’s preference into account and use his preferred bash over the one his system shipped with.
Solution no. 2:
To start the shell-script ‘file.sh’:
Another option is set executable permission using chmod command:
Now run .sh file as follows:
Solution no. 3:
For the bourne shell:
For bash:
Solution no. 4:
If you want the script to run in the current shell (e.g. you want it to be able to affect your directory or environment) you should say:
or
Note that /path/to/script.sh can be relative, for instance . bin/script.sh runs the script.sh in the bin directory under the current directory.
Solution no. 5:
First, give permission for execution:-chmod +x script_name
- If script is not executable:-
For running sh script file:-sh script_name
For running bash script file:-bash script_name - If script is executable:-
./script_name
NOTE:-you can check if the file is executable or not by using ‘ls -a’
Run Unix Executable On Mac
Solution no. 6:
The file extension .command is assigned to Terminal.app. Double-clicking on any .command file will execute it.
Solution no. 7:
Little addition, to run an interpreter from the same folder, still using #!hashbang in scripts. Acrobat pro dmg 7.
As example a php7.2 executable copied from /usr/bin is in a folder along a hello script.
Unix Executable File Converter For Mac Free Online
To run it:
Android emulator rotate. Which behave just as equal as:
The proper solutions with good documentation can be the tools linuxdeploy and/or appimage, this is using this method under the hood.