bad interpreter: No such file or directory
Earlier today I was trying to run a Python script that I downloaded from the internet. Bash (or the kernel, to be exact) refused to run the script, insisting that python didn’t exist:
$ mem.py -bash: /home/natan/bin/mem.py: /usr/local/bin/python2.5^M: bad interpreter: No such file or directory
The script agreed to run indirectly with python ~/bin/mem.py
I googled and discovered that the file was encoded in DOS format with improper line endings.
To fix the problem, I copied the contents of the file and pasted them into a new file. Voilà. The shebang became magical again.
Then again, you can also fix the problem permanently. (Don’t.)
ln -s sh "sh$(printf "\r")"
photo credit: Sven & Lirion
About Me
20 year old undergrad in CS & Physics, co-founder of Freeversation, and former software developer at Check Point.
I am interested in social startups, information security, and robotics. Read more about me
Contact
Email aantny [at] gmail [dot] com. If it's interesting, I can code it.
It seems to me that it would be appropriate to patch the kernel to treat \r\n as end-of-line when processing #! lines.
I don’t think it’s a kernel issue. The “culprit” seems rather the shell. Maybe there’s a command line option or an environment variabile to make the magic happen.
It’s the kernel. Bash doesn’t run executable files – the kernel does that.
There’s a good explanation on Wikipedia detailing how shebangs work.
http://en.wikipedia.org/wiki/Shebang_(Unix)#History
Shebang is intented to the shell (as said on wikipedia).
The system call used to read from a file is “read” wich read a fixed size which is not dependent of end of line characters.
Then it is only a bash issue of how it deals with end of lines as the error message speaks for itself.
It’s not a bash issue. On modern UNIX operating systems, the shebang is parsed by the kernel.
For example, the Linux shebang implementation is located in linux/fs/binfmt_script.c:
(http://lxr.post-tech.com/source/fs/binfmt_script.c?v=linux-2.6.29-c100-a)
How about the dos2unix command or using sed?
Thanks, I didn’t know about dos2unix.
I would just go with a simple fix: dos2unix mem.py
Yeah, that’s a classic problem… can’t find interpreter^M. Ultimately, the only good answer is to not combine Unix-style shebang lines with Windows-style line formatting (and avoid Windows formatting in general).
I encountered a similar problem today (the text was full of DOS line endings), and I found the following solution useful: http://vim.wikia.com/wiki/File_format#Converting_the_current_file
The ^M at the end on your “/bin/python2.5^M:” error message indicates this is due to messed up line endings, as Roshan discovered. It looks like you are trying to execute a file created with DOS line endings in a UNIX environment.
Thanks!
You saved hours of work there….