[Bioperl-l] standardize shebang line in bioperl scripts
carandraug+dev at gmail.com
Thu Sep 13 09:50:18 UTC 2018
On Thu, 13 Sep 2018 at 04:36, Steven Lembark <lembark at wrkhors.com> wrote:
> On Wed, 12 Sep 2018 17:10:25 +0100
> Carnë Draug <carandraug+dev at gmail.com> wrote:
> > 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.
> Q: Then why are people seeing it on the disk?
> If anyone sees #!/usr/bin/perl on the disk they are fried.
> It is no harder to replace '#!/usr/bin/env perl' with your preferred
> path than it is to replace '#!/usr/bin/perl'. The difference is that
> with a simple shell script (either their own or provided by you) the
> users can have whichever perl they prefer.
> > 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.
> Q: What if the version of perl used for the install is a symlink?
> In that case the link may be replaced without you having any control
> over were it points to. If you readlink the path and hardwire it then
> you prevent anyone from choosing their own version by setting the path
> or a symlink -- both well-proven approaches on *NIX.
> > 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.
> No, it is not theoretical. The general approach of using your path
> to determine the executable in use at any time is a practical approach
> that generally works well. In the case you describe above, if the path
> has to be one specific perl then prefix your path with the path to it
> and /usr/bin/env perl will provide the correct results every time.
> The problem is that hardwiring the path oviates any number of other
> effective approaches to managing the executable path that work well
> in a variety of situations.
> If having the path to a specific perl is that important to you then
> either prefix it to your path, provide a symlink like
> "/opt/bin/bio-perl" that can be used to run things, provide a shell
> script that prefixes speciric perl's path
> (e.g., /opt/bin/run-bioperl ...).
> The point is don't assume that you know more about how someone else
> manages their Perl distributions than they do, or that packaging
> approaches for Debian are suitable for all distributions of Linux,
> Unix, and VMS.
We are using MakeMaker for installation and it's MakeMaker that's
setting the shebang. If you want the shebang to be "env", then set
PERL_MM_SHEBANG=relocatable for the installation.
Any change to this logic, can't be unique to the bioperl project and
will be better discussed in MakeMaker and other toolchains used for
More information about the Bioperl-l