Run pyc file without specifying python path ?

[Barak, Ron]

> -----Original Message-----
> From: Dave Angel [mailto:davea at dejaviewphoto.com] 
> Sent: Thursday, July 30, 2009 16:03
> To: Barak, Ron
> Cc: 'Dave Angel'; 'python-list at python.org'
> Subject: RE: Run pyc file without specifying python path ?
> 
> Barak, Ron wrote:
> >> -----Original Message-----
> >> From: Dave Angel [mailto:davea at ieee.org]
> >> Sent: Wednesday, July 29, 2009 21:05
> >> To: Barak, Ron
> >> Cc: 'python-list 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.