Assuming you have the filename ahead of time, just parse it yourself:

our $file = '/etc/profiles/bashrc.ora.v.10';
open my $fh, "< $file" or die "open: $!";

while (defined($_ = <$fh>))
{
    next unless /^export\s+([A-Za-z]\w+)=(.*)$/;
    $ENV{$1} = $2;
}

close($fh);
[download]

That would probably work fine for a majority of cases, where the shell script for environment setup tends to be pretty simple and explicit. It's a good-enough solution when you know enough about the shell script to trust that it will work.

But I can easily imagine (and have seen) examples where the value assigned to a relevant exported variable refers to some other shell variable that was set previously in the same file (and not necessarily exported), or is the output of some back-ticked command, or other arcane cleverness. For shell scripts like that, you really don't want this approach.

True, but the original author hinted that the file contained only simple environment variables in the vein of ORACLE_SID and similar.

There's probably a CPAN module already that handles the special cases and back-ticks, in fact...

--rjray

tilly wrote Get default login environment, and the discussion shows some changes to the script. This is what you want, except that you will likely not want the default login environment but instead your Oracle setup script.

If the environment hasn't been set up in the shell, then parsing "bash --env" isn't going to help him. He needs to parse the env-file itself.

--rjray

Uh - I was thinking of instead just running the login shell running the login shell and then sourcing the file-to-be-sourced, and then dumping env:

perl -e '$env = `/bin/ksh -c ". /vol1/osabst/.wms_profile; env"`; prin
+t $env'
[download]

The process of parsing that output is the same as the process of parsing the login environment.

Update: s/\sset/env/, as per shmem's comment

SID:ORACLE_HOME:<Y|N>
[download]

Now I only have one database but I do run scripts via cron whereby the environment isn't always correct. I then set ORACLE_HOME and ORACLE_SID in a <BEGIN> block or just in the script. Both seem to work.

With Sybase I seem to need a conditional bit of code that checks for the environment variable SYBASE and if not existing then sets it and execs the script over itself. This may be needed to point to different libraries but with Oracle you should only need one set of libraries to use as the client even if connecting to a different database.

I guess I could write a wrapper shell script but that then means two files to maintain.

It seems to me the answers given so far are too complicated because everyone wants to write Perl where they don't need it. You want a shell script instead. Source the environment file to set up the environment, then start the Perl script.

#!/bin/sh

source /etc/profiles/bashrc.ora.v.10
perl program.pl
[download]

And, if your Perl program is already running and the profile file has changed, you can exec the script again, effectively starting fresh.

Minor point: I'd add "exec" in front of "perl". Reduces overhead a minor bit. It's sorta like the the goto &NAME in Perl, but bigger.

#!/usr/bin/perl

print "Starting...\n";

use constant ENVSCRIPT => '/etc/profiles/bashrc.ora.v.10';
if (!$ENV{ORACLE_HOME} && !$ENV{SKIP_ENVSCRIPT})
{
  $ENV{SKIP_ENVSCRIPT}=1;
  exec("/bin/sh -c '. @{[ENVSCRIPT]}; exec $0'");
}

print "ORACLE_HOME=$ENV{ORACLE_HOME}\n";
[download]

If $ENV{ORACLE_HOME} is unset, it runs a copy of the shell to first source the environment file, then re-execute your script. $ENV{SKIP_ENVSCRIPT} keeps this from looping if there are problems.

One caveat is that if the script is run like perl your_script.pl the exec may not work. If that's how you normally call your script, you should be able to adjust the shell line to take that into account.