Skip to main content

Python script mysteriously refuses to run on Unix


Introduction

I was writing a new Python script (actually, a replacement for a bash script) at work today. I have a Windows laptop at work and in my projects and I often do development on Windows but the real objective is for the scripts and other work to run in a Unix system running under VirtualBox and Vagrant. To be exact, the system is: 
Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-143-generic x86_64)

Anyway, I was writing away and it worked ok up to a point on Windows but it needed resources on the Unix system so you might say it failed miserably but I was ready to try it on the virtual machine. When I tried, I got: 
(venv) vagrant@vagrant-host:/vagrant$ bruno/foobar.py --foo
: No such file or directory
(venv) vagrant@vagrant-host:/vagrant$

What the hell? That's a terrible error message. As an aside, I think some Python error messages can be awful and don't do a good job at fixing the problem. I think Python is a superb language but its error messages are not always the best.
Anyway, the error looked familiar but I couldn't remember what was wrong or how to fix it right off the bat. Some other facts:
  • The script uses #! /usr/bin/env python because the virtual machine has a newer version of Python in the $PATH which is supposed to override the system Python and I wanted to make use of it.
  • The script works fine if I do type python bruno/foobar.py --foo from the virtual machine command line but I don't want to have to do that.
  • I created the script on Windows using gvim
  • Remember, the script works fine from Windows!

Long story, short

After battling with this for several minutes, it finally dawned on me that I could be a poor victim of the Curse of the Carriage Return! When you create files on Windows, the file often has a carriage return character the precedes every newline character. Windows notepad is notorious for that - not only does it use carriage returns when you save a file but if you try to open a file that doesn't have carriage returns, it kind of acts like there are no newlines at all. Sometimes this can cause problems if you try to use the file in Unix or you might see funny symbols when you edit the file. There might be an option to not do that with gvim - I'll have to check that out.

I have a script called nocrs that can remove carriage returns on a file. Using that fixed up my script! Gosh, I just realized it's a bash script but that's ok with me.

Labels:

Comments

  1. John (aka Bruno)February 26, 2019 at 8:47 AM

    Recently I went back and rewrote my nocrs script as Python. I think I might have even made use of the logging and argparse modules. I've been loving using those lately.

    ReplyDelete

Post a Comment

Popular posts from this blog

Why I don't like Python 3

Why I don't like Python 3 Python 3 sucks.  I hate that they've made changes so that aren't backwards-compatible.  You can't run many Python 2 scripts using the Python 3 interpreter.  It's almost like they've gone out of their way to piss off developers. Here are some specific reasons why I hate Python 3: My biggest gripe: print is a function rather than a statement now.  I'm not saying it's not a good idea for print to be a function but why fuck with existing scripts?  Just keep the print statement as-is and create a new function with a distinct name. Data read from files comes back as bytes and you have to encode them.  More on this later but I think this is nonsense. You can't write a simple string to a file opened for binary.  Yes, I know about string.encode() but my point is I don't like having to use it. You can't turn off buffering when you open a text file for writing: open('foo', 'w', 0) throws  can...
1 comment
Read more

Python 2 vs 3: the print war

Disclaimer I will be upfront and say I think Python 3 made a terrible mistake by making is so that Python 2 scripts would no longer work. Most of my experience has been with Python 2 and I'm used to using the print statement to print a line to stdout . I hate that Python 3 makes you call print as a function. Yes, I know there are other differences and they're threatening to stop supporting Python 2 starting 2020/01/01. I don't know what I'll do after that point. I suppose Python 2 will still be around but it won't be improved and bugs will not be fixed and I may be ok with that. What can you deduce from print(expression) ? I've started a new job, looking at new code, and was without knowing much about the execution environment, I was beginning to believe that they must be using Python 3 because I saw something like the following in a Python script: print(expression) This seemed to be a reasonable conclusion. However, I also found code in the P...
Post a Comment
Read more

GNU date on Windoze

I love the Cygwin package on Windoze. I'm more of a Unix guy and can't stand the Windows command prompt. I much prefer a standard shell such as bash across all platforms. At my current job, I'm doing most of my development on Windows and our setup makes it so that I have to rely on Git bash more but I still have Cygwin installed and use it for things that aren't so tied to work. Git bash pisses me off sometimes with relation to copy and paste, especially inside the vi editor! What's up with that? So this post's focus is on the date command. One of my few peeves about Cygwin is the default behavior of the command on Windows: Tue, Apr 3, 2018 7:26:52 AM The whole reason for using Cygwin was to have a shell environment that looks and acts like Unix. This does not look like Unix. And GNU being what it is, Git bash works the same way! Yes, my OCD is obvious... some people might say Well, that's close but I don't like this behavior! Uni...
2 comments
Read more