in reply to Debugging PAR packaged programs

God that is offensive code! No wonder you are having problems. Have you considered a module to manage your config files. cpan:Config::Auto is something that comes to mind.

Basically, if you are going to do something like this(ie: something that has been done already). Try and find a module that does it for you and maybe you can avoid these sorts of issues.

Replies are listed 'Best First'.
Re^2: Debugging PAR packaged programs
by Zen (Deacon) on Dec 09, 2008 at 16:27 UTC
    This is not always possible in certain environments, Herkum, due to the local political climate. Knowing how to write something correctly given the tools available is legitimate, even if a module out there does it cleaner. The other thing about modules is the lack of maintenance and occasional setup errors that turn folks off to the whole experience.
[reply]

      Absolutely true, and mind-numbingly aggravating. I hear "only use core" all the time, or maybe "only use what you can find via yum in the official repositories for this antiquated CentOS version we're using." It's like telling me to only run my car only with what was in it when I bought it, or maybe using the resources available at the dinky little gas station around the corner from my apartment.

      It takes little research to discover what modules are available and actively maintained. Unfortunately, that's not enough to satisfy a corporate policy that fears the outside world. Pardon me, I need to go find a brick wall to smash my head against for a few minutes.

      Oh, that original could would be at least a little cleaner if it just split each line into a key/value pair and stored the results in a config hash. It wouldn't necessarily solve the problem of the missing value, but it would be easier to debug by reducing lines of code.

      Now about that brick wall ...

[reply]

      It may not always be possible but that is not the case here. It is bad code, and the programmer needs to fix it. The easiest way for them would be for them to use a module. It would solve two issues, it makes them more flexible to new solutions, and there is a good chance that it will work better than anything that is home grown.

      It is easy to say its corporate politics that prevents me from doing 'blah' and continue doing what you are doing.

      I find that it leads to people who think they know more than they do, writing more code than they should and introducing bugs because of things they have not thought of before... And more than likely, they just did not ask!

[reply]
        I live in a strict political climate, myself. My only point here was not to discourage the use of modules but not to chastise folks who need to roll their own as being ridiculous for trying. Half the time I see veteran SOPW'ers on here saying, "Please do not tell me to use Modules," but I do not think that takes away from the legitimacy of the question or poster.
[reply]
[reply]
        No, you can't, Grandfather. For example, code contamination rules.
[reply]

In Section Seekers of Perl Wisdom