-
Using pickle for data marshaling in an intrusion detection project? No thanks, Lockmart.
https://github.com/lmco/laikaboss/blob/master/laikad.py#L499
-
-
I recognize the potential problem with the “direct” approach, but it seems like the
envapproach just trades one problem for another (namely, that a user with a$PATHthat prefers a different python interpreter than the script’s author intended can end up with unexpected breakage – a situation I find myself in somewhat often, for various reasons). Personally, I very much prefer the obvious, unambiguous immediate-ENOENTfailure mode of the former to the who-knows-what-might-go-wrong-or-how-or-when of the latter, so I stick with the plain old hard-coded absolute path.-
Chalk me up as another hater of non env shebangs in scripts. Don’t presume /usr/bin/python is what you want, all the problems you specify with PATH being messed up exist with /usr/bin/python too.
What if /usr/bin/python is python3 and not python2? What if the user installed python to /usr/local/bin? What if their script is running on nixos where jack and squat is in /usr/bin?
If a user modifies their PATH to point to a different interpreter, that is the whole point of the env shebang line. Unexpected breakage? Well yeah, but if we stick to /usr/bin/BLAH we get the same problem.
With env? PATH=/python/2.7/bin:$PATH scriptname vs /python/2.7/bin/python $(which scriptname)
Want to run it on 2.6? PATH=/python/2.6/bin:$PATH scriptname vs /python/2.6/bin/python $(which scriptname)
Alternative without env means you specify python entirely or rewrite the shebang line to be the sane env line. Assuming /usr/bin/python exists on your target system is as bad of an assumption here. A worse one in my opinion. You’re probably OK if you only ever run on linux, but as someone that had to deal with multiple unixes in the past, env is by far the better iocaine powder here.
-
-
Yep, nixos is the most unique unix like distro in this regard. But /usr/bin/env is present there for a good reason and for shebang lines is basically it. But if you’ve ever written “portable” scripts where some things are in /usr/sfw, other os’s in /opt, etc…. /usr/bin/env is a real nice thing to use and depend on.
Besides I consider /usr/bin/… to normally be out of date, wrong, compiled wrong, doesn’t have the things I need, etc… But I’ve had to deal with too much old unix probably and am just angry at hpux and solaris at this point.
-
It’s… ultimately, any script relies on the user to tell it where the tools it needs are. $PATH is a mechanism for that, and much simpler than editing the source, which is the major alternative. If the user doesn’t think about it or gets it wrong, bad things happen, and that’s not avoidable.
Or we could avoid it by making all Unix software portable. hollow laugh
-
-
-
-
-
That can work for stuff that you make for yourself, but when you try to distribute something you either test every OS/distro possible or.. you just use env.
As a FreeBSD user I’m really sick of people going /bin/bash.. or even worse, doing /bin/sh assuming it’s an alias of bash.
-
-
-
-
This is why I like vagrant for managing OS deps and virtualenv for building python deps. You can share code that bootstraps itself with its env variable and executable path, installs the python libs, and then when the user runs it with something like a shell script all the path references are in place, and the only sudo usage required is to install pip and virtualenv (if not included in the distro already)
-
-
-
Based on the giant red warning message on python’s website, I’d say you’re right.
-
There is an important distinction to make here: that warning says not to unpickle a pickle file from an untrusted source, it’s not a warning about pickling malicious data. I don’t know if that’s a difference in kind or not, but I think the case can be made that the first is a 100% terrible idea and the second unwise but more difficult to exploit.
-
-
This is why it’s so important to stop, let go, and just be something else outside of your engineering and technological brain. We’re not machines, we have to eat, sleep, be loved, love and take care of ourselves. Computers are here so they can manage uptime, always be available, and do the annoying little meticulous things that have to be thought out, and then put down. All the eastern philosophy and new age stuff was just another complexity added to an already too busy mind. Even with intense monastic zen practice, you still eat, sleep, and have people there to help you if you go too far off the deep end. Any hallucinations you might experience are just that, and nothing to be held on to. Grasping onto the experience becomes delusion, and one of the poisons and sicknesses so often talked about in zen training. Tapping into our subconsciousness, and our lucid dreaming states can elicit profound experience, but balance, knowing when to stop, when to let go, when to disengage; these are all parts of a balanced practice. That said, I think the industry is prone to self destructive life styles, and that it’s probably easy to get in a state where you no longer think you have time to sleep, making everything much much worse, like a positive feedback loop. Eat right, get sleep, drink water, exercise, be human! Kenneth Reitz, I think a lot of us probably look up to you for writing about this and your contributions to open source. I know I do, and on behalf of myself and others I say, thank you and please take care of yourself. There are probably lots of people around you who care, you just need to reconnect with them.