perl中的@INC出了什么问题？

Question

让我们想象一下,我们是perl的新手并写了一些很棒的模块MyModule.pm.我们还写了一些很棒的脚本myscript.pl,需要使用这个模块.

use strict;
use warnings;
use MyModule;
etc...

现在我们将创建dir /home/user/GreatScript并将我们的文件放入其中.并试图运行myscript.pl...

cd /home/user/GreatScript
perl myscript.pl

大!现在搬到另一个目录......

cd /
perl /home/user/GreatScript/myscript.pl

获取一些不太有用的错误@INC和路径列表.这是什么？现在经过一些谷歌搜索我们知道@INC包含搜索我们的模块的路径,这个错误意味着Perl找不到MyModule.pm.

现在我们可以:

• 添加到系统PERL5LIB var的路径,它将我们的路径添加到@INC 将我们的模块安装到其中一个目录的开头@INC
• @INC在BEGIN添加use lib '/home/user/GreatScript';到我们的脚本部分中手动添加我们的路径,但它看起来很糟糕.如果我们将脚本移动到其他目录怎么办？
• 或者使用FindBin模块来查找我们当前的目录,并使用此路径use lib "$FindBin::Bin";,但它不是100%有效,例如mod_perl或问题的一些错误......
• 或者使用__FILE __(或$ 0)变量并使用模块中的abs_path方法从中提取路径Cwd.看起来像又一辆自行车？
• 或者有些遗忘或遗失(我错过了什么？)

为什么这种明显和常规的操作需要大量的工作？如果我有一个脚本,那很容易......但是为什么我需要在我的所有脚本中编写这几行额外代码？它不会100%工作!为什么perl @INC默认情况下不添加当前脚本目录,就像"."一样？

PS:我正在寻找我的问题的答案,但只找到上面列表中的解决方案列表和其他一些解决方案.我希望这个问题重复......

Answer 1

或者有些遗忘或遗失(我错过了什么？)

另一种选择:不要将模块与脚本保持一致.该模块是独立的,因为它是可重复使用的,因此将其放在库文件夹中.这可以是用于个人项目的本地库,包括use lib(并且可能引用您为项目设置的环境变量),将模块转换为CPAN库,以及cpan管理它的去向.您决定做什么取决于代码的可重用性,除了脚本使用它的方式.

为什么这种明显和常规的操作需要大量的工作？

事物计划中的工作并不多.您期望在文件系统中组合在一起的文件应由Perl在语言级别自动使用以解析require或use声明.这并不是说不可能,或者你的期望是不合理的,只是Perl没有这样实现.在事实之后改变它可能会影响现有项目的工作量,并且可能会引起争议 - 所以不太可能改变.