in reply to require without the exec

From all sorts of perspectives, ( not *just* nice design principles :) ), I'd suggest you move the data fom the install script into a db / textfile / module / Data::Dumper'ed whatever, and then using it from both scripts - trying to include a whole bunch of code simply to retrieve some static data seems a bit overkill, not to say problematic...

Cheers,
Ben.

Replies are listed 'Best First'.
Re: Re: require without the exec
by melguin (Pilgrim) on May 22, 2003 at 20:37 UTC
    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.
        The only problem being that this is future-proofing for when the install script *changes* - it may be just the data, or the way it's organised, in which case, all parsing bets may be off.
        Ben.