Cheers,
Ben.

Excellent points, and I agree. With all of the other install/modify scripts I wrote surrounding this one, I do use text files for the data that may change -- that way the person updating in the future doesn't have to know my code, just make a list of what packages they want installed and in which order.

However, the big problem is that I can't modify code in the "other" installer that I need to write an uninstaller for--It would make my life easier if I could just rewrite it, though. Thus the need to grab from from it. Actually, half of the installer is hashes

Sorry - I misunderstood the degree of control over the code you had. Surely though, if *somebody* is able to change the installer (and is likely to in the future), could some communication not happen between the two of you? If you wrote a patch for *their* code to read *your* datafile, would it be accepted? (Make it seem like it was their idea, but you're prepared to do all the work - always works for me {g}).

Sorry too to suggest a 'social engineering' solution, but short of (as was suggested by skx) parsing the file, it's looking like your best hope :)

Cheers,
Ben.

If you can't modify the installer, then the only option I see is to parse the install script, although this seems sort of ridiculous. It sounds like you can view the code of the installer, so parsing the code shouldn't be too difficult. Just be sure to do some sort of checking so you don't eval malicious code.

For a module, "loading" it will initialize these things and that's all, until you call something else inside it. But for a script, you want to have it execute the lines that set up your data structures, but then stop before doing the "main" code. That could be mixed in, and there is no general way to tell. However, the structure of your script might make it clear: in the simplest case, copy just the top N lines to a temp file and load that.

use Data::Dumper;
open(F, ">uninstall.dat") || die "Opening uninstall file failed: $!\n"
+;
print F Dumper \%hash;
close(F);
[download]

 You said you can't modify the installer; so I'll not suggest writing both to read the files from a configuration file... Although that's clearly the optimal solution.

 Is the installer sufficiently well formed that you could parse it manually, and extract the files from that?

 If not you might look at some of the sandboxing modules for evaling, but removing dangerous options from their reach - not a great solution but a possible area to explore.

_________
broquaint

... You probably are.
See require for the why ...
The file must return true as the last statement to indicate successful execution of any initialization code, so it's customary to end such a file with 1; unless you're sure it'll return true otherwise. But it's better just to put the 1;, in case you add more statements.

Have a nice day
All decision is left to your taste

Here's the code that does it in case this can help out anyone else:

my %SERVICE;
open (INSTALL, "install.pl") or die "$!";
while (<INSTALL>) {
        if (/my\s+%SERVICE\s+=\s+\(\s*$/) {
                $read = 1;
                next;
        }
        # just in case there are some values on the first line
        if (/my\s+%SERVICE\s+=\s+\(\s*"([^"]+)"\s+=>\s+"([^"])\s*,/) {
                print "\t\"$1\"\t=> \"$2\",\n";
                $SERVICE{$1} = $2;
                $read = 1;
                next;
        }
        if ($read) {
                 # if there's something on the last line of the hash
                if (/"([^"]+)"\s+=>\s+"([^"])\s*\)\s*;/) { $service .=
+ $1; last; }
                 # if there's not
                if (/([^\)]\));/) { $service .= $1; last; }
                 # or if we're not on the last line grab the values
                if (/"([^"]+)"\s+=>\s+"([^"]+)"\s*,\s*$/) { $SERVICE{$
+1} = $2 }
        }
}
close INSTALL;
[download]

        "/etc/rc2.d/S88sendmail"        => "Sendmail",
[download]

Again, thanks everyone.