如何在与脚本相同的目录中找到Perl模块 [英] How to locate Perl modules in the same directory as the script

查看:136
本文介绍了如何在与脚本相同的目录中找到Perl模块的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

现在,Perl的最新版本已删除了."来自@INC的我对模块文件位置的最佳做法感到好奇.到目前为止,与我们网站上每个应用程序关联的* .pm文件与脚本位于同一目录中.我认为,这会创建一个安全漏洞.

Now that recent versions of Perl have removed "." from @INC, I'm curious about best practices for module file location. Until now, the *.pm files associated with each application on our web site were in the same directory as the scripts. This, I gather, creates a security vulnerability.

我们没有对@INC中其余目录的写访问权.

We don't have write access to the remaining directories in @INC.

我们可以只保留pm文件,然后将use lib ".";添加到我们所有现有的脚本中,但这不只是保留安全漏洞吗?

We could just leave the pm files where they are, and add use lib "."; to all our existing scripts, but wouldn't this just preserve the security vulnerability?

根据这项新开发成果,关于如何最好地组织我们的Perl脚本及其相关模块的任何建议吗?

Any suggestions on how our Perl scripts and their associated modules can be best organized in the light of this new development?

推荐答案

否,将模块与脚本放置在同一目录中不是安全漏洞.假设当前工作目录(.)是脚本的目录,则是一个bug和一个安全漏洞.

No, placing modules in the same directory as the script isn't a security vulnerability. Assuming the current work directory (.) is the script's directory is a bug and a security vulnerability.

.是脚本所在的目录. (实际上,一次又一次,人们发现CGI脚本中的./.)只需继续使用您应该已经使用的内容即可:

. was never guaranteed to be the directory in which the script is located. (In fact, time and time again, people have found . to be / in CGI scripts.) Just keep using what you should already be using:

 use FindBin qw( $RealBin );
 use lib $RealBin;

这篇关于如何在与脚本相同的目录中找到Perl模块的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆