On Jul 30, 4:47 pm, "Barak, Ron" <ron.ba...@lsi.com> wrote: > > -----Original Message----- > > From: Dave Angel [mailto:da...@dejaviewphoto.com] > > Sent: Thursday, July 30, 2009 16:03 > > To: Barak, Ron > > Cc: 'Dave Angel'; 'python-l...@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-l...@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. > > Hi Dave, > > > 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 > > The clever I try to guard against is not at hacker level, just the curios > worker. > > > 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. > > Granted, but the user will know that from the user manual anyway :-) > > > > > You imply you want it to run unmodifed on multiple unknown > > Linux versions. I think that lets out binfmt solutions. > > Actually, no: I know the set of Linuxes my users are likely to have. > > > 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 > > Thanks for the helpful suggestions. > Ron.
how can a compiled python file (pyc) can defend your code against clever-user? Try command cat "yourcode.pyc" and you will is how "hardly" it can be read or modified :). The most easy way how to distribute such file is with some shell batch containing #!/usr/bin/sh python ./lib/myscript.pyc the topology of the app would be a shell script called simply run, or name of your app and something like that and a folder called lib where your pyc file is stored, just make the script executable (chmod a+x shellfile or chmod 755 shellfile) and force ppl to use it instead of the pyc file in the lib folder :) -- http://mail.python.org/mailman/listinfo/python-list
