I'm trying to learn a bit of Python3, so, first things first: Hello World. But as simple as it is, I'm having a terrible time with line 1, the Shebang reference. I create the following script on my laptop running Mac Os 10.15.3
#!/usr/bin/env python3
print('Hello World')
I save it as python_test-01.py, make the script executable, and try to run it
Emonda:Scripts paul$ chmod 755 python_test-01.py
Emonda:Scripts paul$ ls -l
-rwxr-xr-x# 1 paul staff 47 Mar 5 13:07 python_test-01.py
Emonda:Scripts paul$ ./python_test-01.py
./python_test-01.py: line 1: #!/usr/bin/env: No such file or directory
./python_test-01.py: line 2: syntax error near unexpected token `'Hello World''
./python_test-01.py: line 2: `print('Hello World')'
Hmm. Can't find env. OK, I'll use a direct path in the shebang line instead of env. I edit the script to read
#!/usr/bin/python3
print('Hello World')
and run it
Emonda:Scripts paul$ ./python_test-01.py
./python_test-01.py: line 1: #!/usr/bin/python3: No such file or directory
./python_test-01.py: line 2: syntax error near unexpected token `'Hello World''
./python_test-01.py: line 2: `print('Hello World')'
Now it can't find Python3 either. So I look around to make sure I actually have env and python3 installed and where they are.
Emonda:Scripts paul$ cd /usr/bin/
Emonda:bin paul$ pwd
/usr/bin
Emonda:bin paul$ whereis env
/usr/bin/env
Emonda:bin paul$ whereis python3
/usr/bin/python3
Yep, there they are, right where I said they would be in the Shebang line. /usr/bin/
A Second Chapter
After kicking this over again and again, I decide to try something different. I ssh over to my Raspberry Pi running Debian GNU/Linux. I note that it too has a version of Python3 installed in its /usr/bin/ directory. I use vim to write the same two line script starting with the same shebang: #!/usr/bin/python3 . Chmod 755. "Hello World". It works the first try.
What is so different between these two systems? Everything worked as expected in the Raspberry Pi. What's up with the Mac? Where should I be looking on the mac to find the reason the interpreter can't find Python3?
Thanks aging for hanging in there with me,
Paul
After all this and all of your great input, it turns out that the script file on the MacOs system was saved UTF-8 with BOM. That was enough to make first line of the script, the Shebang, illegible to the interpreter. After saving the file the the UTF-8 no BOM encoding, it worked as expected.
Related
I have the following python file:
vagrant#vagrant-ubuntu-trusty-64:~/my_app$ cat version_py3.py
#!/usr/bin/env python3
print "Python 2 print statement"
and I thought python version_py3.py will enforce the use of python3. But the code ran fine. and python3 version_py3.py gives expected error.
vagrant#vagrant-ubuntu-trusty-64:~/my_app$ python3 version_py3.py
File "version_py3.py", line 3
print "Python 2 print statement"
^
Also, there is no /usr/bin/env folder on my linux. Am I missing something here with the shebang right, but Python 2 and Python 3 are both installed on my computer.
vagrant#vagrant-ubuntu-trusty-64:~/my_app$ python -V
Python 2.7.6
vagrant#vagrant-ubuntu-trusty-64:~/my_app$ python3 -V
Python 3.4.3
vagrant#vagrant-ubuntu-trusty-64:~/my_app$
When you execute a script and you want have the shebang line respected, you may not prepend "python" in the command. A binary executable as the head of a command, which could work in she-bang as well, any given she-bang is ignored because the command executable is always preferred by the kernel.
Example: So let's assume you have a little python script, but with cat in the shebang. What happens when you set the executable bit of the script and call it as the command head is that the system first reads the first line, strips off the initial two bytes and tries to execute the (mandatorily binary) executable and feed it the script file.
$ /tmp/getver
#!/bin/cat
import sys
print( sys.version )
And now try and see yourself prepending python, python2 and/or python3.
Trivia: The interpreter may choose to process the shebang another time, on its own. E.g. perl used to respect any flags like -w given, whether it is given on the shebang or on the command, no matter if perl is the command head.
Try to located the python installation with locate for example, and set it in your shebang, like #!/usr/bin/python3.6 . I bet it's here.
I am not sure if you have found the solution. In python3, the syntax for print is different. The message has to be inside the parenthesis.
Try print("Python 2 print statement")
I'm a definite Python newbie, so the answer here may be obvious. But I'm trying to change a simple .py file's permissions so it can be run directly from the Terminal window (I'm running Python3 from a Macbook). I've entered the shebang line #! /usr/bin/env python3 at the top of my script, but according to the tutorial I'm following, I next need to run the following command:
chmod +x pythonScript.py
But every time I try running this either from Terminal or the Python shell, I get the following syntax error:
>>> chmod +x pythonScript.py
File "<stdin>", line 1
chmod +x pythonScript.py
^
SyntaxError: invalid syntax
Any ideas on what I'm missing? How do I change the file permission so I can execute a file directly from the Terminal window?
You probably already figured it out but just in case there are others with a similar question.
Your .py file should be saved to your home folder. Say my file is name.py.
When you open the terminal (with current working directory of your home folder) type the command chmod +x name.py.
Now you will be able to run the file in the terminal by typing ./name.py
only use pythonScript.py if that is the name of your .py file
You should run chmod +x filename and ./filename not in python env(>>>). But in directory
I get the following error (error.message) when I run the following shell script (myscript.sh).
myscript.sh
#!/bin/bash
cd /path/to/ && node app.js
error.message
/path/to/myscript.sh: line 1: #!/bin/bash: No such file or directory
/path/to/myscript.sh: line 2: node: command not found
I have already run the following command line instructions.
command-line
chmod u+x /path/to/myscript.sh
chmod u+x /path/to/app.js
Also, I know I have node installed because when I run:
node -v
I get back:
v5.5.1
I execute myscript.sh via the following AppleScript:
MyApp.applescript
do shell script "bash /path/to/myscript.sh"
Also: which bash returns /bin/bash
What could be causing this error and how can I fix it?
I fixed the first error:
/path/to/myscript.sh: line 1: #!/bin/bash: No such file or directory
By copying a working .sh file I had on my machine and copy/pasting the code from the old file to the new file.
I'm guessing somehow there was a filetype issue or discrepancy despite the fact that I used a .sh extension in the file name.
In the future, I will double check the file type in my Finder utility (Max OS X v10.10.1).
However, I am still seeing the second error:
/path/to/myscript.sh: line 2: node: command not found
Credit goes to #HeadCode and #mh-cbon for helping me figure this out with their comments.
I solved the second problem by running:
myshell.sh
#!/bin/bash
path/to/node path/to/app.js
where path/to/node was found by running
command-line
which node
and path/to/app.js is the actual file tree path to app.js. (In other words, different from path/to/node.)
Getting "command not found" when trying to run shell script file. The file itself is stored in a directory, that is added to PATH, but still, terminal doesn't recognize it as shell script.
Here's the sequence I try:
tajimura/GAMIT% echo $PATH
/usr/local/bin:/usr/bin:/bin:/user/games:/usr/X11R6/bin:/usr/bin/X11:/usr/lib64/jvm/jre/bin:/home/tajimura/GAMIT/gamit/bin:/home/jaimura/GAMIT/kv/bin:/home/tajimura/GAMIT/com
tajirmura/GAMIT% ls /home/tajimura/GAMIT/com/sh_steup
/home/tajimura/GAMIT/com/sh_setup
tajimura/GAMIT% sh_setup
sh_setup: Command not found.
tajimura/GAMIT% sh sh_setup
sh: sh_setup: No such file or directory
tajimura/GAMIT% l /home/tajimura/GAMIT/com/sh_setup
-rwxr-xr-x 1 tajimura users 11109 Aug 20 2013 /home/tajimura/GAMIT/com/sh_setup
Here is a screenshot:
PS: Opensuse 12.1 here.
ADDED: I was executing it just fine during first 4 days, so I guess hashbang is not an issue. But I can't guarantee that workstation wasn't rebooted between my sessions, so maybe (just may be) -noexec is the cause. However, script sits in my home directory on hard disk, it's not a removable drive.
ADDED: The first five lines of sh_setup:
/home/tajimura% sed 5q /home/tajimura/GAMIT/com/sh_setup
#!/bin/csh -f
#
#doc Check and setup the GAMIT tables directory
#doc
#
Your script is either not executable (make it so with chmod +x sh_setup) or it specifies a broken (non-existing) interpreter on its hash-bang line (the first line of the sh_setup file, starting with #!).
Your sh sh_setup invocation fails because it doesn't use $PATH and you're in the wrong directory.
EDIT: Your script is clearly executable (I didn't spot this in your screenshot at first), which leaves us with a possibly incorrect interpreter.
I've found an unexpected solution of the problem. If I call the script under bash instead of csh everything is good.
Question: I get this error message:
export: bad interpreter: No such file or directory
when I execute this bash script:
#!/bin/bash
MONO_PREFIX=/opt/mono-2.6
GNOME_PREFIX=/opt/gnome-2.6
export DYLD_LIBRARY_PATH=$MONO_PREFIX/lib:$DYLD_LIBRARY_PATH
export LD_LIBRARY_PATH=$MONO_PREFIX/lib:$LD_LIBRARY_PATH
export C_INCLUDE_PATH=$MONO_PREFIX/include:$GNOME_PREFIX/include
export ACLOCAL_PATH=$MONO_PREFIX/share/aclocal
export PKG_CONFIG_PATH=$MONO_PREFIX/lib/pkgconfig:$GNOME_PREFIX/lib/pkgconfig
PATH=$MONO_PREFIX/bin:$PATH
PS1="[mono-2.6] \w # "
But the bash path seems to be correct:
asshat#IS1300:~/sources/mono-2.6# which bash
/bin/bash
asshat#IS1300:~# cd sources/
asshat#IS1300:~/sources# cd mono-2.6/
asshat#IS1300:~/sources/mono-2.6# ./mono-2.6-environment
export: bad interpreter: No such file or directory
asshat#IS1300:~/sources/mono-2.6# ls
download mono-2.4 mono-2.4-environment mono-2.6 mono-2.6-environment
asshat#IS1300:~/sources/mono-2.6# cp mono-2.6-environment mono-2.6-environment.sh
asshat#IS1300:~/sources/mono-2.6# ./mono-2.6-environment.sh
export: bad interpreter: No such file or directory
asshat#IS1300:~/sources/mono-2.6# ls
download mono-2.4-environment mono-2.6-environment
mono-2.4 mono-2.6 mono-2.6-environment.sh
asshat#IS1300:~/sources/mono-2.6# bash mono-2.6-environment
asshat#IS1300:~/sources/mono-2.6#
What am I doing wrong? Or is this a Lucid Lynx bug?
I did chmod + x
The first line, #!/bin/bash, tells Linux where to find the interpreter. The script should also be executable with chmod +x script.sh, which it appears you did.
It is highly likely that you created this file with a windows editor, which will place a <cr><lf> at the end of each line. This is the standard under dos / windows. OS X will place a <cr> at the end of each line. However, under Unix / Linux, the standard is to just put a <lf> at the end of the line.
Linux is now looking for a file called /bin/bash<cr> to interpret the file,
where <cr> is a carriage return character, which is a valid file character under Linux. Such a file doesn't exist. Hence the error.
Solution: Edit the file with an editor on Linux and get rid of the extra <cr>. One tool that usually works when the file is edited on Windows is dos2unix.
Could the script be using Dos newlines?
Try running dos2unix on it.
It looks like things have been configured to override the export builtin somehow. This can be done via an exported function or the enable builtin, for example. Try putting type export in the script to check. If you are setting BASH_ENV, you probably shouldn't.
If bash is called as sh, it enables POSIX mode and does not allow export to be overridden with a function, as required by POSIX. Likewise, most other shells installed as /bin/sh follow POSIX in this and/or do not allow the execution environment of a script to be messed up so strongly as through importing functions from the environment.
By the way, the script seems designed to be sourced, i.e. . ./mono-2.6-environment instead of ./mono-2.6-environment.
Had the same problem. Used brute force:
/bin/sh /full/path/to/configure --options
& this did the trick
(Of course I'd like to know why)
I encountered a similar error but in my case I forgot to add / before bin and I was encountering the bad interpreter error. Also tried to do
sudo apt-get install dos2unix -y package.
I was using this originally :
#! bin/bash ( i was missing / before bin )
Double check the path as well.
This could be a case of a shebang with homoglyphic unicode characters. In other words, you may have invisible or look-alike characters in the shebang which don't actually represent the string #!/bin/bash. Try looking at the characters in a hex editor.
what worked for me was when dos2Unix wasn't on the system I was working with:
sed -i s/{ctrl+v}{ctrl+m}// filename
This happens sometimes when file system goes funny.
Try to move or rename the file.
If you see "Stale file handle" error this is your problem.
e.g. happened us with CentOS docker
$ ./test.sh
-bash: ./test.sh: /bin/bash: bad interpreter: Invalid argument
$ ls -alstr test.sh
20 -r-xr-xr-x 0 omen omen 17874 Jun 20 01:36 test.sh
$ cp test.sh testcopy.sh
$ ./testcopy.sh
Happy Days
$ mv test.sh footest.sh
mv: cannot move ‘test.sh’ to ‘footest.sh’: Stale file handle
$ rm test.sh
rm: cannot remove ‘test.sh’: Stale file handle
You can copy the file and read it.
But not move it!
Nor remove it.
Some weird docker file-system thing maybe.
Solution: re-create the docker container OR maybe file system repair disk would help
OR of course format c: :-D :-o