Run pyc file without specifying python path ?

[Processor-Dev1l]

On Jul 30, 4:47 pm, "Barak, Ron" <Ron.Ba... at lsi.com> wrote:
> > -----Original Message-----
> > From: Dave Angel [mailto:da... at dejaviewphoto.com]
> > Sent: Thursday, July 30, 2009 16:03
> > To: Barak, Ron
> > Cc: 'Dave Angel'; 'python-l... at python.org'
> > Subject: RE: Run pyc file without specifying python path ?
>
> > Barak, Ron wrote:
> > >> -----Original Message-----
> > >> From: Dave Angel [mailto:da... at ieee.org]
> > >> Sent: Wednesday, July 29, 2009 21:05
> > >> To: Barak, Ron
> > >> Cc: 'python-l... at 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:
>
> > >>> [root at VMLinux1 python]# cat test_pyc.py #!/usr/bin/env python
>
> > >>> print "hello"
> > >>> [root at VMLinux1 python]#
>
> > >>> and made its pyc file executable:
>
> > >>> [root at VMLinux1 python]# ls -ls test_pyc.pyc
> > >>> 4 -rwxr-xr-x  1 root root 106 Jul 29 14:22 test_pyc.pyc
> > >>> [root at VMLinux1 python]#
>
> > >>> So, I see:
>
> > >>> [root at VMLinux1 python]# file test_pyc.py*
> > >>> test_pyc.py:  a python script text executable
> > >>> test_pyc.pyc: python 2.3 byte-compiled
> > >>> [root at VMLinux1 python]#
>
> > >>> If I try to do the following, no problem:
>
> > >>> [root at VMLinux1 python]# python test_pyc.pyc hello
> > >>> [root at VMLinux1 python]#
>
> > >>> However, the following fails:
>
> > >>> [root at VMLinux1 python]# ./test_pyc.pyc
> > >>> -bash: ./test_pyc.pyc: cannot execute binary file
> > >>> [root at 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 :)