Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Trying to get casperjs running on Ubuntu 12.04. After installing it when I run I get:

09:20 $ ll /usr/local/bin/casperjs
lrwxrwxrwx 1 root root 26 Nov  6 16:49 /usr/local/bin/casperjs -> /opt/casperjs/bin/casperjs

09:20 $ /usr/bin/env python --version
Python 2.7.3

09:20 $ cat /opt/casperjs/bin/casperjs | head -4 
#!/usr/bin/env python

import os
import sys

09:20 $ casperjs
: No such file or directory

09: 22 $ python
Python 2.7.3 (default, Sep 26 2013, 20:03:06) 
[GCC 4.6.3] on linux2

So Python is present and runnable, casperjs is pointing to the right place and it is a python script. But when I run it I get "No such file".

I can fix it by changing the first line of the casperjs python file from:

#!/usr/bin/env python




$ casperjs --version

I managed to fix it, but I'm wondering why it didn't work with #!/usr/bin/env python, since that seems to be a normal interpreter line. Do I have something configured wrong?

Here are the steps to get casperjs:

$ git clone git://
$ cd casperjs
$ ln -sf `pwd`/bin/casperjs /usr/local/bin/casperjs
$ casperjs
: No such file or directory
share|improve this question
Can you try running strace /usr/local/bin/casperjs on the nonworking version? Would be helpful if we could see which files env tries to exec, and whether env is failing to find python or python is failing to open the script. – Mark Plotnick Nov 7 '13 at 20:54
@MarkPlotnick ran that, 100s of lines of output, anything in particular? – jcollum Nov 7 '13 at 21:17
Any lines emitted just prior to : No such file or directory being output that contain attempted execve's. [edit: just saw Gilles' answer. Check for lines in the strace output that look like execve("/usr/bin/python\r", ...). ] – Mark Plotnick Nov 7 '13 at 21:36
up vote 21 down vote accepted

If you see the error “: No such file or directory” (with nothing before the colon), it means that your shebang line has a carriage return at the end, presumably because it was edited under Windows (which uses CR,LF as a line separator). The CR character causes the cursor to move back to the beginning of the line after the shell prints the beginning of the message and so you only get to see the part after CR which ends the interpreter string that's part of the error message.

Remove the CR: the shebang line needs to have a Unix line ending (linefeed only). Python itself allows CRLF line endings, so the CR characters on other lines don't hurt. Shell scripts on the other hand must be free of CR characters.

To remove the Windows line endings, you can use dos2unix:

sudo dos2unix /usr/local/bin/casperjs

or sed:

sudo sed -i -e 's/\r$//' /usr/local/bin/casperjs

If you must edit scripts under Windows, use an editor that copes with Unix line endings (i.e. something less brain-dead than Notepad) and make sure that it's configured to write Unix line endings (i.e. LF only) when editing a Unix file.

share|improve this answer
I've run into this issue but it always has an ^M at the end. I'm exclusively in Ubuntu here but still gedit puts that ^M in sometimes, so I went to Geany. Anyway it will give a different error and that's not the error that I'm seeing. – jcollum Nov 7 '13 at 21:17
@jcollum ^M another way to say CR. – Gilles Nov 7 '13 at 21:18
Yes I understand that but what I'm saying is that I'm not getting that error any longer, so it's not a line break issue. – jcollum Nov 7 '13 at 21:25
@jcollum You removed the CR when you edited the shebang line. If you change it back to #!/usr/bin/env python (without adding back a CR), it will work. – Gilles Nov 7 '13 at 21:31
Well I'll be, you were right. Is it safe to say that those CRLFs are in the source? I opened it up in geany and got this: If you can configure Ubuntu to use CRLFs instead of LFs I have no idea how, so it seems unlikely that I did it. – jcollum Nov 7 '13 at 21:42

This behaviour is because the system only looks for binaries specified in the $PATH

command to see what paths the binaries are looked for

echo $PATH

if you would like to run it from the other directory

mayby you should type it with a slash like this


or try using export to include the path /usr/bin/env/python to $PATH command

share|improve this answer
The /usr/bin/env is not a path. It is a command. Adding the slash there won't fix anything. And the #! notation in scripts does not execute with $PATH at all, which is why one needs to specify the full path, or use /usr/bin/env python here. – dobey Nov 7 '13 at 20:42
If the program wasn't in the PATH, the error message would be “command not found”. The shebang line is correct except for the spurious CR at the end, what you propose is gobbledygook. – Gilles Nov 7 '13 at 21:15
And, if python weren't in the PATH, the /usr/bin/env python --version command that the OP performed successfully would not have succeeded. – Scott Jan 3 at 13:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.