The environment variables of the shell are available through the %ENV hash in Perl. See perlvar for it.

The easiest way to make the variables available to a Perl script is to set them up beforehand:

#!/bin/bash

. ~/.bash_profile
/path/to/your/perlscript.pl
[download]

If that is not possible, you can follow the approach outlined in Get default login environment to get the environment variables that the script sets up. Specifically, RE (tilly) 3: Get default login environment has a subroutine that does what you want.

TIMTOWTDI:

#!/usr/bin/perl

use POSIX;
use String::ShellQuote qw(shell_quote);

unless (defined $ENV{CTC_HOME}) {
  $ENV{DONT_LOOP_FOREVER}++ or die "infinite loop detected";
  exec "source ~/.bash_profile && ".shell_quote($^X, $0, @ARGV);
  POSIX::_exit(255);
}

chdir($ENV{CTC_HOME});
...
[download]

Though, I have to admit I prefer the simpler shell wrapper solution given by Corion.

I think the one drawback of re-executing yourself like that is that you lose Perl command line switches like -Ilib etc. ... There is Devel::PL_origargv, which gives you the original command line, but I'm not sure that I would want to go such an esoteric length when a shell script can do the same.

Just a note as to why you're getting these other solutions: when you're using backticks or system or whatever to run your source command a completely new shell is starting up, running the commands in the source'd script and changing that new shell's environment, and then that shell exits and any modifications disappear. The *NIX process model doesn't allow a child process to modify its parent's environment (as is noted in perlfaq8, "I {changed directory, modified my environment} in a perl script. How come the change disappeared . . .?" )

my $bashcode=<<'__bash__';
    source ~/.bash_profile;
    perl -MData::Dumper -e 'print Dumper \%ENV';
__bash__

my $VAR1;
eval qx{bash -c "$bashcode"};

my $dir = $VAR1->{CTC_HOME};
[download]

explanation here:

Re^3: How to "source" a shell file in Perl?

HTH! :)

Hm ... probably it's much easier, and you are just missing the obvious. ..

... please check if your environment was already set from your parent process, before trying the other workarounds.

print $ENV{CTC_HOME}

See also %ENV

If you wish to make CTC_HOME available as part of the environment in your script you can update %ENV in the code:

use strict;
use warnings;

local %ENV = %ENV; # NOTE: local is used here in case you wish to 
                   # restore the original %ENV in a different scope
                   # of this script
$ENV{CTC_HOME} = q{/Inf/work/};
# ... now "CTC_HOME" is available for all child
# processes (via fork, system, ``, etc) of $0 (this script)
[download]

Given this idiom, you could then pass in CTC_HOME as a commandline argument or, better still, as a configuration file that you can then parse via Config::Tiny. That said, you could also just make sure the environment is set up as you wished via ~/.bash_profile before execution to avoid all of this. I am still not sure why you want to effect ~/.bash_profile. It almost seems like you're wishing to ensure an environment via command invoked via ssh. In this case, note that ssh has options that allow you to pass remote environmental viariables via the ssh command itself.