Re: Run pyc file without specifying python path ?
Barak, Ron wrote:
-Original Message-
From: Dave Angel [mailto:da...@ieee.org]
Sent: Sunday, August 02, 2009 12:36
To: Barak, Ron
Cc: 'python-list@python.org'
Subject: Re: Run pyc file without specifying python path ?
Barak, Ron wrote:
Hi Dave,
It seems like I don't understand your solution.
I use the (attached) soapAPI.py as the wrapper to parsing.pyc.
However, if I do (for instance):
$ python -u parsing.pyc -U aaa
The last line of the output is (as expected):
return_code: 12 ; params: {'username': 'aaa'}
But, if I try the following:
$ soapAPI.py -U aaa
I don't get this line. Only the output to stderr gets
printed to the screen.
Bye,
Ron.
Hi Ron,
To make it easier for anybody following this thread, let me
post the minimum equivalent source files, inline.
parsing.py:
--
#!/usr/bin/env python
import sys
def main():
print sys.stderr, This is stderr output
return 5, sys.argv
if __name__ == __main__:
return_code, params = main()
print return_code:,return_code,; params:,params
sys.exit(return_code)
---
soapapi.py:
---
#!/usr/bin/env python
import sys
import parsing
parsing.main()
--
When I run soapapi.;py, it indeed prints only the stderr output.
The solution is to move (most or all) of the top-level code
of parsing.py into a main() function. Since you already have
a main(), I'll rename that, and make a new one that calls it.
new parsing.py:
---
#!/usr/bin/env python
import sys
def innermain():
print sys.stderr, This is stderr output
return 5, sys.argv
def main():
return_code, params = innermain()
print return_code:,return_code,; params:,params
sys.exit(return_code)
if __name__ == __main__:
main()
---
The output is now two lines, one from innermain(), and one
from main().
And it's the same whether the user runs parsing.py or soapAPI.py
To clarify what happened, realize that when the user invokes
parsing.py, the module is considered a script, and gets a
pseudo-name of
__main__When that same module is imported by another one, it is
considered a library module, and gets its own name parsing
So any logic that explicitly checks for __main__ has to
change, because we want identical behavior in the two cases.
DaveA
Hi Dave,
Trying your above scripts, I get other results than you do. E.g.:
$ python parsing.py --help
return_code: 5 ; params: ['parsing.py', '--help']
This is stderr output
$ python soapapi.py --help
This is stderr output
$
So, in my environment (cygwin on win xp, python Python 2.5.2) I'm getting
different results than you get, namely - soapapi.py on my environment does not
show the stdout output.
On which environment did you get identical results from your parsing.py and
soapapi.py ?
Bye,
Ron.
$ cat parsing.py
#!/usr/bin/env python
import sys
def main():
print sys.stderr, This is stderr output
return 5, sys.argv
if __name__ == __main__:
return_code, params = main()
print return_code:,return_code,; params:,params
sys.exit(return_code)
$ cat soapapi.py
#!/usr/bin/env python
import sys
import parsing
parsing.main()
Please read my message again, especially starting with the words the
solution is. I showed two versions of parsing.py, and you're still
using the broken version. I posted both versions, with descriptions of
what I changed and why, so that you could see why the change was important.
I'm using sys.version == 2.6.2 (r262:71600, Apr 21 2009, 15:05:37)
[MSC v.1500 32 bit (Intel)] Running on XP Sp3. And 2.5 will
give identical results, though I don't have it installed any more.
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
RE: Run pyc file without specifying python path ?
-Original Message- From: Dave Angel [mailto:da...@dejaviewphoto.com] Sent: Thursday, July 30, 2009 20:08 To: Barak, Ron Cc: 'python-list@python.org' Subject: Re: Run pyc file without specifying python path ? Barak, Ron wrote: 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 (Please don't top-post. It puts responses out of order) You don't have to do anything special. Any module can import sys, and parse sys.argv, as long as it wasn't yet modified. DaveA Hi Dave, It seems like I don't understand your solution. I use the (appatched) soapAPI.py
Re: Run pyc file without specifying python path ?
Barak, Ron wrote:
Hi Dave,
It seems like I don't understand your solution.
I use the (appatched) soapAPI.py as the wrapper to parsing.pyc.
However, if I do (for instance):
$ python -u parsing.pyc -U aaa
The last line of the output is (as expected):
return_code: 12 ; params: {'username': 'aaa'}
But, if I try the following:
$ soapAPI.py -U aaa
I don't get this line. Only the output to stderr gets printed to the screen.
Bye,
Ron.
Hi Ron,
To make it easier for anybody following this thread, let me post the
minimum equivalent source files, inline.
parsing.py:
--
#!/usr/bin/env python
import sys
def main():
print sys.stderr, This is stderr output
return 5, sys.argv
if __name__ == __main__:
return_code, params = main()
print return_code:,return_code,; params:,params
sys.exit(return_code)
---
soapapi.py:
---
#!/usr/bin/env python
import sys
import parsing
parsing.main()
--
When I run soapapi.;py, it indeed prints only the stderr output.
The solution is to move (most or all) of the top-level code of
parsing.py into a main() function. Since you already have a main(),
I'll rename that, and make a new one that calls it.
new parsing.py:
---
#!/usr/bin/env python
import sys
def innermain():
print sys.stderr, This is stderr output
return 5, sys.argv
def main():
return_code, params = innermain()
print return_code:,return_code,; params:,params
sys.exit(return_code)
if __name__ == __main__:
main()
---
The output is now two lines, one from innermain(), and one from main().
And it's the same whether the user runs parsing.py or soapAPI.py
To clarify what happened, realize that when the user invokes
parsing.py, the module is considered a script, and gets a pseudo-name of
__main__When that same module is imported by another one, it is
considered a library module, and gets its own name parsing
So any logic that explicitly checks for __main__ has to change,
because we want identical behavior in the two cases.
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
RE: Run pyc file without specifying python path ?
-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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Run pyc file without specifying python path ?
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
RE: Run pyc file without specifying python path ?
-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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Run pyc file without specifying python path ?
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. Hey Ron, What i usually do to accomplish this is compile the script to a .pyc just like you did and then call that pyc from another script that's not compiled. so in your case the not compiled script looks like: #!/usr/bin/env python import test_pyc.pyc then run that script... hope this helps... alternatively you might have a look at: http://www.pyinstaller.org/ gr Arno-- http://mail.python.org/mailman/listinfo/python-list
Re: Run pyc file without specifying python path ?
Barak, Ron wrote: 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. Ask Google for binfmt-support. Hint: Each Python version has its own magic header. Christian -- http://mail.python.org/mailman/listinfo/python-list
Re: Run pyc file without specifying python path ?
On Thu, 30 Jul 2009 07:01:28 +0100, Barak, Ron wrote: 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. What do you think the c in .pyc stands for? What it's not is a compiled to machine-code stand alone executable. 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. It's not the clever users you need to worry about, because they'll fix your bugs. It's the not-as-clever-as-they-think-they-are users you have to worry about. But frankly, the best way to deal with them is to make it absolutely clear that you don't provide free support for modified versions of the script, and as soon as they report a problem, you diff their version with the official version. If they vary, then you start charging them. Before you go spending vast amounts of time and energy creating a fragile solution, it's worth you working out what it actually is you're trying to prevent. If it's just I don't want anybody touching my precious, precious code! then I have no sympathy and have no interest in helping you. If it's The damn users have mucked up the script AGAIN and now they expect me to fix it for free!!!, then that's a social problem, not a technical one, and a social solution might save you a lot of wasted effort. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
RE: Run pyc file without specifying python path ?
From: PythonAB [mailto:pyt...@rgbaz.eu] Sent: Thursday, July 30, 2009 12:18 To: Barak, Ron Cc: 'Dave Angel'; 'python-list@python.org' Subject: Re: Run pyc file without specifying python path ? 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. Hey Ron, What i usually do to accomplish this is compile the script to a .pyc just like you did and then call that pyc from another script that's not compiled. so in your case the not compiled script looks like: #!/usr/bin/env python import test_pyc.pyc then run that script... hope this helps... alternatively you might have a look at: http://www.pyinstaller.org/ gr Arno [BR] Thanks for the answer Arno. But, I wonder - How is your suggestion, which to the user would look like: python wrapper.py different (from the user's point-of-view) than the following: python test_pyc.pyc ? I'm trying to avoide having to write python on the command line. Of course, I could write the wrapper is bourne shell, but that interoduces other problems (especially when considering that my real application needs to parse many command line options). . Bye, Ron. -- http://mail.python.org/mailman/listinfo/python-list
Re: Run pyc file without specifying python path ?
On Thu, Jul 30, 2009 at 3:42 AM, Barak, Ronron.ba...@lsi.com wrote: From: PythonAB [mailto:pyt...@rgbaz.eu] Sent: Thursday, July 30, 2009 12:18 To: Barak, Ron Cc: 'Dave Angel'; 'python-list@python.org' Subject: Re: Run pyc file without specifying python path ? 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. Hey Ron, What i usually do to accomplish this is compile the script to a .pyc just like you did and then call that pyc from another script that's not compiled. so in your case the not compiled script looks like: #!/usr/bin/env python import test_pyc.pyc then run that script... hope this helps... alternatively you might have a look at: http://www.pyinstaller.org/ gr Arno [BR] Thanks for the answer Arno. But, I wonder - How is your suggestion, which to the user would look like: python wrapper.py No, with the shebang line (and assuming execute permissions on the file), it would look like: ./wrapper.py (or just `wrapper.py` depending on whether the file is placed in the $PATH) Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Run pyc file without specifying python path ?
On 30 jul 2009, at 12:57, Chris Rebert wrote: On Thu, Jul 30, 2009 at 3:42 AM, Barak, Ronron.ba...@lsi.com wrote: From: PythonAB [mailto:pyt...@rgbaz.eu] Sent: Thursday, July 30, 2009 12:18 To: Barak, Ron Cc: 'Dave Angel'; 'python-list@python.org' Subject: Re: Run pyc file without specifying python path ? 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. Hey Ron, What i usually do to accomplish this is compile the script to a .pyc just like you did and then call that pyc from another script that's not compiled. so in your case the not compiled script looks like: #!/usr/bin/env python import test_pyc.pyc then run that script... hope this helps... alternatively you might have a look at: http://www.pyinstaller.org/ gr Arno [BR] Thanks for the answer Arno. But, I wonder - How is your suggestion, which to the user would look like: python wrapper.py No, with the shebang line (and assuming execute permissions on the file), it would look like: ./wrapper.py (or just `wrapper.py` depending on whether the file is placed in the $PATH) Cheers, Chris yes exactly, chris you can distribute a pyc containing your program, and have the wrapper.py execute it gr Arno -- http://mail.python.org/mailman/listinfo/python-list
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
Re: Run pyc file without specifying python path ?
On 2009-07-30, Dave Angel da...@dejaviewphoto.com wrote: 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. That won't stop a dedicated reverse-engineering effort. It might take an X-ray machine, machine tools, various nasty chemicals, and quite a bit of skill and patience -- but it can be done. 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. Or even being able to benefit from change. :) -- Grant Edwards grante Yow! FROZEN ENTREES may at be flung by members of visi.comopposing SWANSON SECTS ... -- http://mail.python.org/mailman/listinfo/python-list
RE: Run pyc file without specifying python path ?
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
Re: Run pyc file without specifying python path ?
On 2009-07-30, Barak, Ron ron.ba...@lsi.com wrote: 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). I don't understand your problem. The module would parse sys.argv just like always. If you don't like that for some reason, you could define an entry point in the module and call it: #!/usr/bin/python import sys,test_pyc test_pyc.main(*sys.argv) -- Grant Edwards grante Yow! We just joined the at civil hair patrol! visi.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Run pyc file without specifying python path ?
Barak, Ron wrote: 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 (Please don't top-post. It puts responses out of order) You don't have to do anything special. Any module can import sys, and parse sys.argv, as long as it wasn't yet modified. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Run pyc file without specifying python path ?
En Thu, 30 Jul 2009 12:16:46 -0300, Unknown unkn...@unknown.invalid escribió: On 2009-07-30, Barak, Ron ron.ba...@lsi.com wrote: 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). I don't understand your problem. The module would parse sys.argv just like always. If you don't like that for some reason, you could define an entry point in the module and call it: #!/usr/bin/python import sys,test_pyc test_pyc.main(*sys.argv) And you *should* do it that way, instead of just importing the other module and executing ALL the program as a side-effect of the import statement. In the first case, the import lock will prevent other threads to run. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Run pyc file without specifying python path ?
In article mailman.3949.1248951463.8015.python-l...@python.org, Chris Rebert c...@rebertia.com wrote: No, with the shebang line (and assuming execute permissions on the file), it would look like: ./wrapper.py There's no reason to name it .py; you can have a perfectly useful shell script that just happens to list python on the shebang line instead of the usual /bin/sh. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Many customs in this life persist because they ease friction and promote productivity as a result of universal agreement, and whether they are precisely the optimal choices is much less important. --Henry Spencer -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
