-----BEGIN PGP SIGNED MESSAGE-----
On 10/25/2011 03:21 PM, Adam Williamson wrote:
On Tue, 2011-10-25 at 20:39 +0200, Michał Piotrowski wrote:
> 2011/10/25 Richard W.M. Jones <rjones(a)redhat.com>:
>> On Tue, Oct 25, 2011 at 08:33:28PM +0200, Michał Piotrowski
>>> 2011/10/25 Chris Adams <cmadams(a)hiwaay.net>:
>>>> Once upon a time, Michał Piotrowski <mkkp4x4(a)gmail.com>
>>>>> I created feature page
I strongly object to this "feature". /bin/sh is a
Unix standard back to
>>>> IIRC around 7th Edition, and there is NO good reason
>>>> break it. The "#!/usr/bin/env foo" suggested replacement
>>>> has always been a hack to work around broken systems, not
>>>> something suggested for all scripts.
>>> What is wrong with #!/usr/bin/env interpreter from technical
>> This is what's wrong:
>> $ cat > sh.sh #!/bin/sh $ cat > env.sh #!/usr/bin/env sh $
>> chmod +x sh.sh env.sh $ time for i in $(seq 1000); do ./sh.sh;
>> real 0m2.737s user 0m0.750s sys
>> 0m1.519s $ time for i in $(seq 1000); do ./env.sh; done
>> real 0m3.677s user 0m1.013s sys
> Yeah, it is noticeably slower - about 0,00094s.
Uh. ~2.7secs vs. ~3.7 secs is nearly one entire second, not one
tiny tiny fraction of a second, isn't it?
There are also possible Security ramifications of allowing the
interpreter to be replaced, users could stumble upon this.
Python even tries to prevent this with the -Es qualifier.
-s Don't add user site directory to sys.path.
-E Ignore environment variables like PYTHONPATH and
modify the behavior of the interpreter.
I think putting
is a very bad idea for administrative tools.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----