* Ruud H.G. van Tol via perl5-porters <perl5-porters@perl.org> [2023-03-14 10:50:48 +0100]: > > On 2023-03-07 10:01, Ovid wrote: > > The problem: a new client is using system Perl for a large product > > that's been running for decades. Many of /their/ clients have the code > > installed locally, so it's non-trivial to fix. > > See also: https://direnv.net/ It is also worth pointing out that one may create a properly isolated shell environment with custom PATHs, aliases, and bash functions by using the following bash option, --rcfile: exec bash --rcfile path/to/some/file.rc I use a similar line in a wrapper script I have that provides a completely isolated Perl environment, but it effectively allows one to have an overlay environment. For example, I use it to: 1. contain a full perl installation (installed initially via perlbrew, probably unnecessarily) 2. install modules via cpanm, that was itself installed via "perlbrew --install-cpanm" 3. retain access to system python2/3 4. maintain an exclusive bin, lib, include directories for different src I build For an interactive environment, this works great. I am not sure how this would work out in start up script or something else non-interactive, but I suspect bash would be quite happy taking an --rcfile in most situations. The nice part is that I can easily enter this environment or exit it, depending on my needs. It also makes it pretty easy to create a portable environment from system to system, that environment being the one created by your custom rcfile. Cheers, Brett > > -- Ruud > -- -- oodler@cpan.org oodler577@sdf-eu.org SDF-EU Public Access UNIX System - http://sdfeu.org irc.perl.org #openmp #pdl #nativeThread Previous | Thread Next