in reply to Re^4: Access system ENV variables from within CGI Script
in thread Access system ENV variables from within CGI Script

You do not seem to understand the shell programming going on there.

The line

echo env | bash --login

[download]

is used to run the env command in an instance of the bash shell running as login shell. It seems though as if your shell is the Korn shell (ksh), so you will either need to adapt Get default login environment to the shell actually used on your system, or use RE (tilly) 1: Get default login environment or RE (tilly) 3: Get default login environment or Re^2: RE (tilly) 3: Get default login environment, which all try to get the shell that is actually your login shell.

So, you need to do some understanding of the Perl program and the shell scripts and how they interact.

Replies are listed 'Best First'.
Re^6: Access system ENV variables from within CGI Script
by Anonymous Monk on Oct 12, 2007 at 13:09 UTC
    here is my test code: 
    #!/opt/appenv/perl/bin/perl

use strict;
use warnings;

use CGI;
use Data::Dumper;

my $q = new CGI;

print $q->header();
my %ENV2;

%ENV2 = (%ENV2, get_login_env());
print Dumper(\%ENV2);

sub get_login_env {
  local %ENV;
  my $shell= '/usr/bin/ksh'; #shift || (getpwuid($<))[8];
    
  my $env = `echo env | /opt/appenv/perl/bin/perl -e 'exec {"$shell"} 
+-sh'`;
  if (wantarray) {
    my @pieces = ($env =~ m/^(.*?)=((?:[^\n\\]|\\.|\\\n)*)/gm);
    s/\\(.)/$1/g foreach @pieces;
    return @pieces;
  }
  else {
    return $env;
  }
}

    [download]
    The only things I have changed from Tillys example is the $shell, since the value it was coming up with was /bin/ksh and not /usr/bin/ksh (since which ksh returns /usr/bin/ksh). And the path to Perl on the machine /opt/appenv/perl/bin/perl. I am starting to follow your comments about an instance of /usr/bin/ksh calling echo env, but I am curious as to why we are only getting few results via the above method. Any advice on how to begin some debugging would help lots. TIA
[reply]
[d/l]

      You will need to look at what actually happens. What the output of `env` is, also the error output. And of course, also what happens in your login/profile scripts. Most likely one of the scripts is not run when no terminal is connected. Adding set -x to the top of all interesting shell scripts will provide lots of informative output of what gets run when. Also, manually logging in as a different user, preferrably with an empty environment, and then running the scripts of your user might prove helpful.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom