Run pyc file without specifying python path ?

[Barak, Ron]

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: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. 
> >   
> 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
> 
> 
>