Hi Dave, On second thoughts, I may have a problem implementing the wrapper solution, because my actual test_pyc.pyc, needs to parse its command line. Namely, the actual call to test_pyc.pyc looks something like this:
$ python test_pyc.py -U dave -PpasswoRD -C CreateMcGroupOnVolume --SVMs_IPs '10.1.1.1 , 10.1.1.2' -n "host1,host2" -g gn -j jn -s svn -t tvn -p pool1 -l -c And I don't know of a way to add these parameters to the "import test_pyc" in wrapper Is there a way to pass information to an imported module ? (Sorry if there's an obvious answer, I just cannot figure it out). Bye, Ron. > -----Original Message----- > From: Dave Angel [mailto:da...@dejaviewphoto.com] > Sent: Thursday, July 30, 2009 16:03 > To: Barak, Ron > Cc: 'Dave Angel'; 'python-list@python.org' > Subject: RE: Run pyc file without specifying python path ? > > 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