Barak, Ron wrote:
-----Original Message-----
From: Dave Angel [mailto:da...@ieee.org]
Sent: Wednesday, July 29, 2009 21:05
To: Barak, Ron
Cc: 'python-list@python.org'
Subject: Re: Run pyc file without specifying python path ?
Barak, Ron wrote:
Hi,
I wanted to make a python byte-code file executable,
expecting to be able to run it without specifying "python" on
the (Linux bash) command line.
So, I wrote the following:
[r...@vmlinux1 python]# cat test_pyc.py #!/usr/bin/env python
print "hello"
[r...@vmlinux1 python]#
and made its pyc file executable:
[r...@vmlinux1 python]# ls -ls test_pyc.pyc
4 -rwxr-xr-x 1 root root 106 Jul 29 14:22 test_pyc.pyc
[r...@vmlinux1 python]#
So, I see:
[r...@vmlinux1 python]# file test_pyc.py*
test_pyc.py: a python script text executable
test_pyc.pyc: python 2.3 byte-compiled
[r...@vmlinux1 python]#
If I try to do the following, no problem:
[r...@vmlinux1 python]# python test_pyc.pyc hello
[r...@vmlinux1 python]#
However, the following fails:
[r...@vmlinux1 python]# ./test_pyc.pyc
-bash: ./test_pyc.pyc: cannot execute binary file
[r...@vmlinux1 python]#
Is there a way to run a pyc file without specifying the
python path ?
Bye,
Ron.
I don't currently run Unix, but I think I know the problem.
In a text file, the shell examines the first line, and if it
begins #!
it's assumed to point to the executable of an interpreter for
that text file. Presumably the same trick doesn't work for a
.pyc file.
Why not write a trivial wrapper.py file, don't compile it,
and let that invoke the main code in the .pyc file?
Then make wrapper.py executable, and you're ready to go.
DaveA
Hi Dave,
Your solution sort of defeats my intended purpose (sorry for not divulging my
'hidden agenda').
I wanted my application to "hide" the fact that it's a python script, and look
as much as possible like it's a compiled program.
The reason I don't just give my user a py file, is that I don't want a cleaver
user to change the innards of the script.
On the other hand, I don't want to make a compiled (freezed?) version of the
application, because it'll grow the resulting file significantly, and I don't
have the experience to know how it will run on different Linuxes.
Bye,
Ron.
Most of the other answers basically paraphrased my suggestion of making
a wrapper file, not compiling it, and making it executable. With that
approach, the user just types "wrapper.py" on his command line.
And wrapper.py only needs two lines, a shebang, and an import, no big
deal if the user modifies it. The rest of your code can be .pyc files.
Steven makes some good points. You have to define what level of clever
you're protecting from. A determined hacker will get in no matter what
you do, unless you want to ship the program in a proprietary embedded
system, encased in epoxy. Further, if you have an extension of .py or
.pyc, a knowledgeable hacker will know it's probably python.
You imply you want it to run unmodifed on multiple unknown Linux
versions. I think that lets out binfmt solutions. That means you need
to test and support not only multiple Linux implementations, but
multiple Python versions, because who knows what the user may have
installed. I think you need to rethink your support strategy. And
maybe concentrate on being able to detect change, rather than prevent it.
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
