http://qs321.pair.com?node_id=562087

skazat has asked for the wisdom of the Perl Monks concerning the following question:

Heya,

I'm having some peculiarities with servers that run Frontpage extensions, and perl cgi apps that have lib files.

I'm not a Frontpage guru, but the program seems to like to create directories called, "_vti_cnf" all over the place - I'm assuming as a cache or a place to put some sort of meta data for the FP program itself.

Fairly ugly. But a weird thing also happens - these directories become part of @INC. File store in the, "_vti_cnf" directories hold the same name as the files they're meta-data'ing/caching - but with different content - which means, if the copy of these files try to get used in a perl app, perl will tell you there's all sort of errors.

The workaround is to just move the app-specific perllib out of wherever the app (in this case, a CGI script) is located, usually in the cgi-bin, and locate it in, say, the home directory.

Here's a diagram of the directory structure: 

cgi-bin
---- script.pl 
---- lib (dir)
-------- Config.pm
-------- Brain.pm
-------- _vti_cnf (dir)
------------ Config.pm

For whatever reason, the copy of, "Config.pm" in the, "_vti_cnf" dir will be used/required etc, even though the program could look like this: 

 

#!/usr/bin/perl 
use lib qw(./lib); 
use Config.pm

[download]

So, is there some sort of workaround, either telling perl not to use the Front Page created directories, or something in Frontpage to tell it to layoff the cgi-bin?

I develop a program (Gnu), that gets installed all over the place, so I have no control over the environment it gets installed in.

Thanks for your help!

 

-justin simoni
skazat me

Replies are listed 'Best First'.
Re: MS Frontpage, _vti_cnf directories and perllibs
by Jenda (Abbot) on Jul 18, 2006 at 19:08 UTC

    The module you have problems with is really called "Config.pm" or is this just an example? Since there is a Config.pm in the .../perl/lib/ already I would expect a lot of errors if you prevent Perl from loading it (by loading your Config.pm first) as well as from not loading your module (if the core Config.pm was already loaded). Rename your module!

    Next question is ... is the working directory what you think it is? I believe some versions of IIS used to set the working directory to the web root, not to the directory containing the script!

    In either case your modules should not be in the web accessible directories, it's better to have them outside the cgi-bin.

    Jenda
    Support Denmark!
    Defend the free world!

[reply]

      The module you have problems with is really called "Config.pm" or is this just an example?

      Just an example. It could be anything - Field.pm, etc.

      Next question is ... is the working directory what you think it is? I believe some versions of IIS used to set the working directory to the web root, not to the directory containing the script!

      We're running Apache on some unix-flavor.

      In either case your modules should not be in the web accessible directories, it's better to have them outside the cgi-bin.

      This is a fine workaround, I was hoping that there was something else - or at least a better understanding of why perl is even looking in these directories.

      There are many popular packages that put perl modules in the cgi-bin. Moveable Type comes to mind.

       

      -justin simoni
      skazat me

[reply]

        OK then, what does this script print? 

        #!perl
use Cwd;
print "Content-type: text/plain\r\n\r\n";

print "Cwd=".cwd()."\n";
print "\@INC=('" . join("', '", @INC)."')\n";

eval "use lib qw(./lib);";
print "\@INC after use lib=('" . join("', '", @INC)."')\n";

eval "use Field;";
if ($@) {
  print "Failed to use Field.pm: $@\n";
} else {
  print "Field.pm loaded from $ENV{'Field.pm'}\n";
}

        [download]

        The reason why you should not put the modules in cgi-bin is that you most likely do not want people to download or execute them, do you? If your scripts are to be installed in $foo/cgi-bin then the libraried may well be in $foo/lib. Thus you'd just use lib qw(../lib); instead. Or maybe rather use Cwd;use lib cwd()."/../lib"; to be safe in case you change the working directory and try to import some more modules later.

        Jenda
        Support Denmark!
        Defend the free world!

[reply]
[d/l]
[select]
        No, skazat, the wisdom Jenda ofered is not "a fine workaround."

        Rather, it is "best practice," SOP and/or doctrine.

[reply]
Re: MS Frontpage, _vti_cnf directories and perllibs
by ww (Archbishop) on Jul 18, 2006 at 18:15 UTC

    OP wrote 'For whatever reason, the copy of, "Config.pm" in the, "_vti_cnf" dir"...' prompting me to wonder if (shifting voice to "direct address"):

    • you are putting it there (intentionally or otherwise)?
        or
    • you believe the presence of config.pm to be an "automatic" feature of FP?
        or
    • the source for what FP pretends is .html may include some sort of reference to config.pm?

    Based solely on the limited info you've provided, I suspect the problem lies in your selection of and linking (eg, coding) to <dir> names, but I'm so rabidly anti-FP that YMMV.

[reply]

      you are putting it there (intentionally or otherwise)?

      Um, no - I'm not putting the _vti_cnf there, nor the Config.pm which is in the _vti_cnf dir. Both are created by FP. I'm sort of scoobied why Perl would search in this directory at all, as it's clearly not in @INC.

      you believe the presence of config.pm to be an "automatic" feature of FP? or

      The creation of the Config.pm file in the _vti_cnf directory is something FP does, when it does it's thing.

      the source for what FP pretends is .html may include some sort of reference to config.pm?

      No. FP isn't reading the (original) Config.pm file as if it was some native module, it's just creating metadata about the Config.pm file, and saving it in a directory called, _vti_cnf in a file called, Config.pm. It's braindead, I know.

      Based solely on the limited info you've provided, I suspect the problem lies in your selection of and linking (eg, coding) to <dir> names,

      Limited? I gave a background, what I think is happening, a bare-bones example script, and then asked for help on some points - since I'm stuck. I think a better word would be concise, or, to the point.

      but I'm so rabidly anti-FP that YMMV.

      Well, if you don't know FrontPage, why are you commenting at all? I don't really have any stance on FrontPage - it's a program, I don't use it, but it is installed on hosting accounts. I make programs that theoretically should run on these hosting accounts, but I'm having problems with this one issue.

       

      -justin simoni
      skazat me

[reply]

        Addressing the last part of your reply, first: I did not say I "don't know FrontPage;" I said, loosely translated, that I don't like it because the code it produces is non-compliant with w3c standards, filled with proprietary bloat, and exceedingly difficult to transform to anything which does meet my standards. Your standards may vary, but please don't twist my words.

        Your observation that "FP isn't reading the (original) Config.pm file as if it was some native module, it's just creating metadata about the Config.pm file, and saving it in a directory called..." seems, in the context your two nodes now provide, to suggest that FP has access to Config.pm... which rings warning bells to me.

        "Limited??" - Yes. Still. No clear statement of OS; no hint of which server software (Apache, IIS, something else?) you're concerned with. And in light of your reply, I'm not even sure if the phrase "hosting accounts" has the same meaning to you that I initially initially credited it with meaning.

        And, finally, your so-called "... bare-bones example script...." illustrates very little of any consequence (except, perhaps, the use lib qw(./lib); suggesting a *n*x-ish OS).

[reply]

Back to Seekers of Perl Wisdom