47

I have several python scripts which work just fine but one script has (as of this morning) started giving me this error if I try to run it from the bash:

: No such file or directory

I am able to run the 'broken' script by doing python script_name.py and after looking around a bit the general idea that I picked up was that maybe my line ending of the hashbang got changed (silently) so I looked at the line ending of a working script and a broken script via the :set list option in VI as indicated in this question -> View line-endings in a text file

Both files appear to end using the same character (a $) so I am kind of at a loss on how to proceed from here. Specifically, how to actually 'see' the line ending in case the set list was not the right method.

PS: The script is executable and the shebang is in there, I stated that it's just this 1 script that was working fine before the weekend but it started giving me this error as of this morning.

-- edit: --

Running the script through dos2unix does get it working again but I would like to know of any way to visualize the line ending somehow in VI(M) or why Geany somehow converted the line endings in the first place (as I never work on a dos/windows system anyhow).

Community
  • 1
  • 1
Bas Jansen
  • 3,273
  • 5
  • 30
  • 66
  • How are you running it? Are you not forgetting the shebang? – Ciro Santilli OurBigBook.com Nov 04 '13 at 09:26
  • 1
    run 'file script_name.py' if it's ASCII text executable, with CRLF line terminators you have to convert the file using dos2unix command – vahid abdi Nov 04 '13 at 09:26
  • Check that `#! /usr/bin/python` is at the top of your file. Or that the file is executable with `sudo chmod 0777 filename` – Inbar Rose Nov 04 '13 at 09:27
  • The shebang is in all my scripts, it's just this one that is not running at all (calling it from the bash by simply doing `./scriptname.py`. – Bas Jansen Nov 04 '13 at 09:27
  • It's probably not executable. – Inbar Rose Nov 04 '13 at 09:27
  • Well. It seems you have a bug in your code then - something the code was relying on no longer exists, it may be useful to print progress messages (or log) so you know WHERE it breaks. – Inbar Rose Nov 04 '13 at 09:28
  • 1
    I have a simple print statement as the first line of the code followed by an immediate exit. The code itself is NOT the problem, I just stated that I can run it fine by calling it via `python scriptname.py` but not via `./scriptname.py` and it is executable. – Bas Jansen Nov 04 '13 at 09:30
  • @Vahidabdi Any way to see what terminators I have because a quick copy of the script and running it through dos2unix did indeed get it working again (which surprises me as I never touch a dos/windows machine for work)? – Bas Jansen Nov 04 '13 at 09:33
  • @BasJansen which editor are you using? i don't know why it's in dos format? – vahid abdi Nov 04 '13 at 09:41
  • @Vahidabdi I am just using Geany. – Bas Jansen Nov 04 '13 at 09:42
  • change the default end of line character using [this](http://geany.org/manual/#files-preferences) – vahid abdi Nov 04 '13 at 09:50
  • 2
    @InbarRose `sudo chmod 0777 filename` is _never_ the answer. – Burhan Khalid Nov 04 '13 at 10:04
  • 2
    To see the line ending style, use the vim command `:set fileformat` or `:set ff` for short. It will show `dos` or `unix`. You can convert the file with `:w ++ff=unix`, or alternatively `:set ff=unix` and then save it normally. – rodrigo Nov 04 '13 at 10:06
  • @rodrigo I will accept that if you make an answer out of it. – Bas Jansen Nov 04 '13 at 10:07
  • That question (and answer) saved me a lot of headaches, I created a script on a windows machine and did not think about the line ending when trying to execute it on a debian machine. Thanks! – Alex Sep 27 '16 at 14:39

4 Answers4

67

From the comments above it looks like you have dos line endings, and so the hashbang line is not properly processed.

Line ending style are not shown with :set list in Vim because that option is only used when reading/writing the file. In memory line endings are always that, line-endings. The line ending style used for a file is kept in a Vim per-file option, weirdly called fileformat.

To see/change the line ending style from Vim, you can use the following commands:

:set fileformat
:set ff

It will show dos or unix. You want unix, of course ;-).

To change it quickly you can save the file with:

:w ++ff=unix

Or if you prefer:

:set ff=unix

And then save the file normally.

So see all the gory details just do :help fileformat, :help file-formats and :help fileformats

rodrigo
  • 94,151
  • 12
  • 143
  • 190
10

You can also use the dos2unix command to convert the file format

dos2unix

This helped me to run the python scripts

This normally happens when we open files in windows do changes and save it. if you open the file locate the ^M characters at the end of every line

Thanks

Community
  • 1
  • 1
Giridhara Kalkere
  • 211
  • 1
  • 4
  • 7
  • 1
    This is in no way an answer to the question. Your answer is even specifically mentioned by myself in the question already. – Bas Jansen Sep 29 '15 at 09:05
3

Personally, I find it kinda wrong using direct path to python interpreter. As you dont use windows platform, you should have program env, usually in /usr/bin (/usr/bin/env). Try using following shebang:

#!/usr/bin/env python

Different distros store python binary in /bin or /usr/bin (or some weird locations), and this one makes your script config-independent (as far as possible, here we have possibility that env is stored elsewhere; still - it is less possible that env is not in /usr/bin than that python is mislocated).

I had similiar problem (if not exactly the same) and that worked for me.

Also, I have both python interpreters (2.7.x and 3.x) installed, so I need to use "python3" argument for env. AFAIR usually distros link different names to different binaries, so "env python" will run python2.7 on my system, "env python3" (also python33, or smth like that) will run p3k, and "env python2" (also python27, etc) will run python 2.7.x. Declaring which version of interpreter should be used seems like a good idea too.

Filip Malczak
  • 3,124
  • 24
  • 44
  • Downvoted: The line endings were the cause of the OP's problem, not this. This is unwarranted editorializing. – Dan H Aug 11 '17 at 21:13
  • I actually agree - post factum I understand that this wasn't adequate answer, though I didn't want to remove it or edit just to repeat someone elses answer. I wouldn't call that as much editorializing as a wrong guess, though that's not the point. – Filip Malczak Aug 13 '17 at 16:38
2

I came across this problem editing my code on Windows, checking it in with git, and checking out and running it on Linux.

My solution was: tell git to Do The Right Thing. I issued this command on the Windows box:

git config --global core.autocrlf true

Modified the files and checked them in; voila, no such problem any more.

As discussed on the Git documentation.

Dan H
  • 14,044
  • 6
  • 39
  • 32