[Bioperl-l] standardize shebang line in bioperl scripts

[Carnë Draug]

On Tue Sep 4 16:15:07 UTC 2018, Steven Lembark lembark at wrkhors.com wrote:
> On Wed, 29 Aug 2018 12:19:54 +0100
> Carn? Draug <carandraug+dev at gmail.com> wrote:
>> Hi
>>
>> I was wondering if there's any consensus about what should be used in
>> the shebang line.  Looking at the existing scripts, I found:
>>
>>     #!perl
>>     #!/usr/bin/env perl
>>     #!/usr/bin/perl
>>     #!/usr/bin/perl -w
>>
>> Using the bioperl distzilla plugin bundle, 'perl' and '/usr/bin/perl'
>> get converted to the path of perl used for the package installation.
>> However, if '/usr/bin/env perl' it remains unmodified.  This behaviour
>> seems to be a bug in MakeMaker [1].
>>
>> To me it makes sense to have the shebang line replaced with the perl
>> used for installation since that's the one that will have the rest of
>> bioperl modules.  But the most important thing, I think, is to be
>> consistent.
>>
>> If no one opposes soon, I will change all of them to '/usr/bin/perl'
>> so that it gets fixed during install.
>
> /usr/bin/perl is the last thing you want to standardize on.
>
>
> POSIX did away with non-absolute path #! lines -- anything with #!perl
> is *old* and no longer works on most systems.
>
> #!/usr/bin/perl is largely unusable as it assumes you are using the
> O/S installed versin of perl, which you usually aren't (unless you
> want to use 5.8 on Centos or 5.10 on Redhat or 5.16 on Amazon linux).
> You normally want to use /opt/perl/bin/perl (linux, SysV),
> /usr/local/bin/perl (BSD), or ~/.perlbrew/whatever (just about
> anything).
>
> There is no good way other than $PATH to determine the preferred
> perl to use. For example, you might change your path when testing
> a new install to /opt/perl/5.26.1/bin/perl just to test that release
> before symlinking it all into /opt/bin.
>
> Net result: "env" is the only sane way to go.
>
> Luvly thing is that env might be installed in /bin/env or /usr/bin/env
> depending on Linux vs. BSD vs. SysV roots of whatever you are running
> Perl on (let alone Windows...).
>
> The one most likely to work is:
>
>     #!/usr/bin/env perl
>
> linux habitually installs env into /bin with a symlink in /usr/bin;
> BSD & SysV install it in /usr/bin maybe-without a symlink in /bin.
>
> I any case using "/usr/bin/perl" either ties you to decade(s) out of
> date perl with the O/S distro or forces you to update the disro perl,
> which may break ancient pieces of the distro itself, and is nearly
> always the wrong thing to do.

You're missing the point.  What gets in the shebang line in the source
release is not what will be in the shebang line after installation.

The source code has three states:

    1. the code in the git repo
    2. the code in the source release
    3. the code installed in the system

During installation the shebang line gets replaced with the perl used
for installation.  But if the shebang line has 'env' then this does
not happen and you may end up with a botched installation.

So we set /usr/bin/perl, not because that is the best perl to be used,
but because that will be transformed in the only perl that we know for
sure can use the modules the scripts are dependent on.

This is not a theoretical issue.  This issue is exactly the reason why
I'm looking into this.  One of the bioperl scripts I was using was no
longer working my env changed to use a perl that had not the bioperl
modules.  This is also Debian Policy, which I care about, because I've
been packaging this for Debian.

---

This also means that people calling the scripts from the git repo
can't do it.  They should have never done it in the first place.  If
people want to run development versions, one needs to build and
install them.  It's not only because of the changing of the shebang
line.  There may be other changes happening to the source during the
release and installation step.  At least, the $version value is set
automatically during release.

Carnë