in reply to How to run a legacy perl version smoothly from perlbrew & Carton

I don't know what Carton is, so just covering this:

Secondly, there are about 200 CGI scripts mostly in Perl, and each with a #!/usr/bin/perl shebang line

find ... -name '*.cgi' -type f \
   -exec perl -pe's{^#!.*?/perl}{#!/.../perl} if $. == 1' -i~ {} \;

[download]
  • Comment on Re: How to run a legacy perl version smoothly from perlbrew & Carton
  • Download Code

Replies are listed 'Best First'.
Re^2: How to run a legacy perl version smoothly from perlbrew & Carton
by Fletch (Bishop) on Dec 17, 2020 at 13:52 UTC

    Alternately replace the hardcoded shebang path with #!/usr/bin/env perl and then you can diddle all of them using PATH rather than editing things in place.

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

[reply]
[d/l]
[select]

      I strongly disagree. You don't want your script, especially a production application, to suddenly start using a different perl (which might not be compatible or might not have the correct modules installed).

      I would create a perlbrew alias for each project and use that. This would allow testing with different versions, etc. by modifying the alias.

[reply]
[d/l]

        Valid point; my counter to that would be that if you've got PATH changing randomly and/or unintentionally for production execution environments then you've got an equally large problem.

        The issue with hardcoding links is that you can't then change the referenced name without altering which perl you get for everything running against the same filesystem usting that name. You also can't trivially test the same copy of script X (especially if it's called via system down n levels deep by several other scripts so you can't easily prefix the call with /my/other/perl X ...) under a different perl without then editing the shebang for script X. And now everyone running that same copy is going to have to run under that different perl; so you really need to make a different copy and you're back to playing games with PATH to have just that tweaked version found first.

        Granted with containers these days it's much easier to get an identical-but-for environment whipped up (in which case it's trivial to go with either approach; depend on PATH or depend on the shebang but you're in a one-off superchroot that can't see anything wrong because there's nothing else on the same "box" for it to see wrong). Pick the approach that works best for you and be aware of the constraints your chosen approach has (hardcoded shebangs means editing and creating a separate copy of scripts to test, whereas PATH lets you change without editing but makes you sensitive to environmental changes).

        Edit: I was otherwise distracted when replying and glossed over the alias bit mentioned below; that's an interesting approach.

        The cake is a lie.
        The cake is a lie.
        The cake is a lie.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom