It's not exactly clear what you mean, so this might be totally off the mark.
You can "freeze" an environment using a Perl script which could be as simple as this trivial example "freeze":
#!/usr/bin/perl -w
use strict;
my $freezer = "frozen.env";
open (FROZEN, ">$freezer")
|| die "Could not write to $freezer\n";
foreach (keys %ENV)
{
print FROZEN "$_=$ENV{$_}\n";
}
close (FROZEN);
Now you can reinstate it using something like this program, which might be called "perform":
#!/usr/bin/perl -w
use strict;
my $freezer = "frozen.env";
open (FROZEN, $freezer)
|| die "Could not read saved environment $freezer\n";
while (<FROZEN>)
{
chomp;
my ($var, $value) = /^([^=]+)=(.*)/;
$ENV{$var} = $value;
}
close (FROZEN);
system (@ARGV);
Once you have established your environment, you would run the first program to "freeze" it. This would churn out a file called "frozen.env" which lists your various environment variables. Note that this program is not very robust, and multi-line entries are going to break it, so you may have to modify it accordingly.
Once you have established your environment, you can use the second program to execute a command in that pre-defined environment, such as:
% perform make
Now, you can use a "dot config" file by replacing the value of $freezer with, perhaps, something like this:
my $freezer = (getpwuid($>))[7]."/.frozenrc";
Note that the getpwuid call returns the home directory for the current user, as defined in /etc/passwd, so this will likely not work in a Win32 environment.
If your make process outputs errors to STDERR, you may have to write a shell script wrapper which can trap these accordingly, or attempt the same with a more ambitious script. I don't have an example of that handy, though. SuperSearch may yield results. | [reply]
[d/l]
[select] |
Tadman, thank you for your reply.
This looks like the direction we will want to move to with future releases.
The problem I am having with our dot .profile configuration files is that they are actually ksh scripts (determining ports, etc) and not just a list of keys and values. I cannot actually determine what values they will produce until install time when the files are in the target directory and they are actually sourced.
I don't like this design, but I am thinking of sourcing the dot configuration files in a ksh script and then calling a Perl script that wraps the make process.
Or, at install time, should I source the dot configuration files in a ksh script that then writes the environment to a "frozen" file, read the "frozen environment" and then put the key/value pairs in the Perl environment hash? And then call make in the "thawed" environment?
These solutions still feel somewhat awkward.
| [reply] |
| [reply]
[d/l]
[select] |