5 ms·

Sorry, but I fail to see where the "env" command spawns a shell: http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/env.c?id=v8.13#n153 http://git.savanna

by etanol 14y ago

Sorry, but I fail to see where the "env" command spawns a shell: http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/env.c?id=v8.13#n153 http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/env.... Could you please explain what am I missing?

nikcub 14y ago
what I mean is that it is just like running 'python' in a shell, not that each instance spawns a new one
- zwp 14y ago
  > like One significant difference: when running python from a shell there's a fork() and an exec(). env(1) doesn't fork: there are not two processes. (In other words: the shell does not exit when you run a command, env vanishes). There is obviously still some overhead to using env (and I just learnt from the source that env has argument processing). I tried to replicate AncientPC's test but on my machine both invocations take around 0.015s. (Perhaps their username is an indication as to why they see a (2%!) difference...). But okay. What I really came here to say is: security. You can make all the efforts in the world to ensure that all programs get called with full pathnames but then one env shebang and you're suddenly open to running whatever's first in the user's $PATH and happens to call itself "python". EDIT: eg http://portaudit.freebsd.org/d42e5b66-6ea0-11df-9c8d-00e0815b8da8.html http://portaudit.freebsd.org/d42e5b66-6ea0-11df-9c8d-00e0815...
  - nikcub 14y ago
    That last point is important which I forgot to mention, especially in operating systems that have '.' first in PATH. I notice the difference anecdotally without measuring it, but I don't know if that is a conception bias because I know env should be slower. The best way would be an autoconf script in your package and an install run that finds and verifies the local framework. I have to admit that I have never done this though. I have a few Python scripts with decent distribution and just rely on the direct path (and a batch file for win32)
  - AncientPC 14y ago
    I've posted my full test scripts and results here: http://williamting.com/2012/04/19/performance-decrease-using-env/ http://williamting.com/2012/04/19/performance-decrease-using... I've been using this handle since '93 out of inertia. My tests were done on an idle i7-620M, sequentially. If your invocation takes about 0.015s, that means you're not looping enough for differences to appear. A 2% increase from 0.015s is 0.0153s, invisible due to significant digits cut off.

by etanol 14y ago

nikcub 14y ago

what I mean is that it is just like running 'python' in a shell, not that each instance spawns a new one

zwp 14y ago
> like One significant difference: when running python from a shell there's a fork() and an exec(). env(1) doesn't fork: there are not two processes. (In other words: the shell does not exit when you run a command, env vanishes). There is obviously still some overhead to using env (and I just learnt from the source that env has argument processing). I tried to replicate AncientPC's test but on my machine both invocations take around 0.015s. (Perhaps their username is an indication as to why they see a (2%!) difference...). But okay. What I really came here to say is: security. You can make all the efforts in the world to ensure that all programs get called with full pathnames but then one env shebang and you're suddenly open to running whatever's first in the user's $PATH and happens to call itself "python". EDIT: eg http://portaudit.freebsd.org/d42e5b66-6ea0-11df-9c8d-00e0815b8da8.html http://portaudit.freebsd.org/d42e5b66-6ea0-11df-9c8d-00e0815...
- nikcub 14y ago
  That last point is important which I forgot to mention, especially in operating systems that have '.' first in PATH. I notice the difference anecdotally without measuring it, but I don't know if that is a conception bias because I know env should be slower. The best way would be an autoconf script in your package and an install run that finds and verifies the local framework. I have to admit that I have never done this though. I have a few Python scripts with decent distribution and just rely on the direct path (and a batch file for win32)
- AncientPC 14y ago
  I've posted my full test scripts and results here: http://williamting.com/2012/04/19/performance-decrease-using-env/ http://williamting.com/2012/04/19/performance-decrease-using... I've been using this handle since '93 out of inertia. My tests were done on an idle i7-620M, sequentially. If your invocation takes about 0.015s, that means you're not looping enough for differences to appear. A 2% increase from 0.015s is 0.0153s, invisible due to significant digits cut off.