[PATCH 1 of 2 V2] contrib: don't hardcode path to bash interpreter

Olle olle.lundberg at gmail.com
Wed Mar 26 06:34:32 CDT 2014


On Wed, Mar 26, 2014 at 12:17 PM, Julien Cristau
<julien.cristau at logilab.fr>wrote:

> On Wed, Mar 26, 2014 at 12:02:44 +0100, Olle Lundberg wrote:
>
> > # HG changeset patch
> > # User Olle Lundberg <geek at nerd.sh>
> > # Date 1395831553 -3600
> > #      Wed Mar 26 11:59:13 2014 +0100
> > # Node ID 6e8b538637302e06a3510d15e36c30757f8501a2
> > # Parent  2a14a2e1ec78f2950da46fedb70686278d90620e
> > contrib: don't hardcode path to bash interpreter
> >
> > Use the env binary to figure out the correct bash to use.
> > Certain systems ships with an ancient version of bash, but the
> > user might have installed a newer one that is earlier in $PATH.
> >
> > For example the current version of Mac OS X ships version 3.2.51
> > of bash, which does not understand new fancy builtins such as
> > readarray. A user might install a newer version of bash, use that
> > as their shell and add that path before bin.
> >
> Why does that mean these scripts shouldn't use the bash version in /bin?
> Do they need any fancy new bash features?
>

Yes, readarray/mapfile arrived in bash 4.

We could probably bail out on version instead. But i see it as good
behaviour to honour what the sysadmin/user wants us to use as bash, as long
as it is bash (just as we do with the hg binary and python):
head -n1 hg
#!/usr/bin/env python

Yes i do know about setuptools and that is replaces it, with the one that
invoked setup.py, but it is still the same concept.

To hardcode the path to the interpreter is just bad behaviour (and stupid).
Whatever way we chose to go the invocation should be through env (be it sh
or bash), else your scripts become bad unix citizens.


> Cheers,
> Julien
> --
> Julien Cristau          <julien.cristau at logilab.fr>
> Logilab                 http://www.logilab.fr/
> Informatique scientifique & gestion de connaissances
>



-- 
Olle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140326/7629a78a/attachment.html>


More information about the Mercurial-devel mailing list