On Tue, Nov 10, 2009 at 01:05:36AM -0600, Frank Cox wrote:
> On Tue, 10 Nov 2009 07:53:30 +0100
> Mogens Kjaer wrote:
>
> > > The file command will verify that for you.
> >
> > Are you sure?
>
> Well, I guess not then. I assumed that "file" would treat a .py file as a text
> file. I don't do any programming with Python and haven't looked at it closely.
>
> "file" tells me that a file that's created with Borland Turbo C (DOS) is
> "data", but a file of C source code that's created with Linux gedit is "ASCII C
> program text".
>
> A text file that's created with the DOS "edit" command is "ASCII English text,
> with CRLF line terminators", and a text file that's created with Linux gedit is
> "ASCII text".
>
> So file can tell the difference in pretty much every case except for a Python
> file. Which may be an oversight in the magic definitions.
I missed the early part so I am not sure what is "Serious"
in this so excuse me for arriving late but it all appears
normal and natural to me.
Python programs are of two types. Text files that are interpreted
at runtime and have a first line that specifies the interpreter:
#! /usr/bin/python
and bytecode python programs.
A text file in DOS mode because the "#!" interpreter fails.
If there is no white space after python the error makes more
sense:
$ ./bar.py
bash: ./bar.py: /usr/bin/python^M: bad interpreter: No such file or directory
If there is white space after the n in python in the #! escape line
the error is less clear.
The script with DOS mode or unix mode new line conventions can be
compiled to python byte code or just executed with python.
$ python ./bar.py
Hello
And compiled.
$ ls -l bar*
-rwxr-xr-x 1 bob bob 36 2009-11-13 20:25 bar.py
$ py_compilefiles bar.py
Compiling bar.py ...
$ ls -l bar*
-rwxr-xr-x 1 bob bob 36 2009-11-13 20:25 bar.py
-rw-r--r-- 1 bob bob 108 2009-11-13 20:29 bar.pyc
$ chmod +x bar.pyc
$ ./bar.pyc
Hello
$ file ./bar.pyc
./bar.pyc: python 2.6 byte-compiled
Since the #! escape for /usr/bin/python is seen in the
text of the script by "file" it "corretly" notices that
this is a python script. I say "correctly" because the
python interpreter and compiler has no trouble with it.