Perl "do",相对路径以“.”开头要么 ”..”
Perl "do", with relative path beginning with "." or ".."
我正在尝试将 Perl 的 do EXPR
函数用作穷人的配置解析器,使用仅 returns 一个列表作为配置信息的第二个 .pl 文件。 (我认为这可能是 do
的理想用法,尤其是因为我可以在我的代码中编写“do or die
”。)这是一个示例:
main.pl
# Go read the config file
my %config = do './config.pl';
# do something with it
$web_object->login($config{username}, $config{password});
config.pl
# Configuration file for main script
(
username => "username",
password => "none_of_your_business",
favorite_color => "0x0000FF",
);
阅读Perldoc for do
给出了很多关于相对路径的有用建议——搜索@INC 和修改%INC,关于5.26 不搜索“.”的特别警告。等等。但它也有这些位:
# load the exact specified file (./ and ../ special-cased)...
Using do with a relative path (except for ./ and ../), like...
然后它从来没有真正费心去解释“./”或“../”的特殊情况路径处理 - 一个重要的遗漏!
所以我的问题都是关于“当你 do './file.pl';
时 真正 会发生什么”的变体?例如...
- 虽然 CWD 从 @INC 中删除,但此语法在 5.26 中是否仍然有效?
- 无论如何从谁的角度来看“./”:Perl 二进制文件、执行的 Perl 脚本、来自用户 shell 的 CWD 或其他?
- 是否存在需要注意的安全风险?
- 这比修改@INC 并仅使用基本文件名好还是坏?
如有任何见解,我们将不胜感激。
好的,所以 - 首先,我不确定你的 config.pl
是否真的是正确的方法 - 对于初学者来说它不是 perl
,因为它无法编译。无论哪种方式,尝试将内容评估为 'parse config' 通常都不是一个好计划 - 它很容易出现令人不快的故障和安全漏洞,因此应保留以备不时之需。
我会敦促您通过以下任一方式以不同的方式进行操作:
写成模块
像这样:
package MyConfig;
# Configuration file for main script
our %config = (
username => "username",
password => "none_of_your_business",
favorite_color => "0x0000FF",
);
然后您可以在主脚本中:
use MyConfig; #note - the file needs to be the same name, and in @INC
并将其访问为:
print $MyConfig::config{username},"\n";
如果您不能将它放在现有的 @INC
中 - 这可能有您不能这样做的原因,FindBin
允许您使用相对于您的脚本位置的路径:
use FindBin;
use lib "$FindBin::Bin";
use MyConfig;
将您的 'config' 编写为定义的可解析格式,而不是可执行代码。
YAML
YAML
对于配置文件来说非常可靠,特别是:
use YAML::XS;
open ( my $config_file, '<', 'config.yml' ) or die $!;
my $config = Load ( do { local $/; <$config_file> });
print $config -> {username};
您的配置文件如下所示:
username: "username"
password: "password_here"
favourite_color: "green"
air_speed_of_unladen_swallow: "african_or_european?"
(YAML 还支持多维数据结构、数组等,不过你似乎不需要这些。)
JSON
JSON
based 看起来很像,只是输入是:
{
"username": "username",
"password": "password_here",
"favourite_color": "green",
"air_speed_of_unladen_swallow": "african_or_european?"
}
您阅读它的方式是:
use JSON;
open ( my $config_file, '<', 'config.json' ) or die $!;
my $config = from_json ( do { local $/; <$config_file> });
使用相对路径配置:
您完全不必担心 @INC
。您可以简单地使用基于相对路径...但更好的选择是不这样做,而是使用 FindBin
- 它允许您指定 "relative to my script path" 并且更可靠。
use FindBin;
open ( my $config_file, '<', "$FindBin::Bin/config.yml" ) or die $!;
然后您就会知道您正在读取与您的脚本位于同一目录中的脚本,无论它是从何处调用的。
具体问题:
From whose perspective is "./" anyway: the Perl binary, the Perl script executed, CWD from the user's shell, or something else?
当前工作目录通过进程向下传递。所以默认情况下用户的 shell,除非 perl 脚本执行 chdir
Are there security risks to be aware of?
任何时候你 'evaluate' 某些东西就好像它是可执行代码(并且 EXPR
可以)都存在安全风险。它可能并不大,因为脚本将 运行ning 作为用户,而用户是可以篡改 CWD
的人。核心风险是:
- 用户在 'different' 目录中,其他人已将恶意内容放入 运行。 (例如,想象 'config.pl' 中有
rm -rf /*
)。也许 /tmp
中有一个 'config.pl' 他们 'run' 不小心?
- 您
eval
正在编写的内容有错字,并且以古怪和意想不到的方式破坏了脚本。 (例如,它可能会重新定义 $[
并从此以后以难以调试的方式扰乱程序逻辑)
- 脚本在特权上下文中执行任何操作。情况似乎并非如此,但请参阅上一点并想象您是
root
或其他特权用户。
Is this better or worse than modifying @INC and just using a base filename?
更糟糕的海事组织。实际上根本不修改 @INC
,而是使用完整路径,或使用 FindBin
的相对路径。并且不要 eval
不必要的事情。
我正在尝试将 Perl 的 do EXPR
函数用作穷人的配置解析器,使用仅 returns 一个列表作为配置信息的第二个 .pl 文件。 (我认为这可能是 do
的理想用法,尤其是因为我可以在我的代码中编写“do or die
”。)这是一个示例:
main.pl
# Go read the config file
my %config = do './config.pl';
# do something with it
$web_object->login($config{username}, $config{password});
config.pl
# Configuration file for main script
(
username => "username",
password => "none_of_your_business",
favorite_color => "0x0000FF",
);
阅读Perldoc for do
给出了很多关于相对路径的有用建议——搜索@INC 和修改%INC,关于5.26 不搜索“.”的特别警告。等等。但它也有这些位:
# load the exact specified file (./ and ../ special-cased)...
Using do with a relative path (except for ./ and ../), like...
然后它从来没有真正费心去解释“./”或“../”的特殊情况路径处理 - 一个重要的遗漏!
所以我的问题都是关于“当你 do './file.pl';
时 真正 会发生什么”的变体?例如...
- 虽然 CWD 从 @INC 中删除,但此语法在 5.26 中是否仍然有效?
- 无论如何从谁的角度来看“./”:Perl 二进制文件、执行的 Perl 脚本、来自用户 shell 的 CWD 或其他?
- 是否存在需要注意的安全风险?
- 这比修改@INC 并仅使用基本文件名好还是坏?
如有任何见解,我们将不胜感激。
好的,所以 - 首先,我不确定你的 config.pl
是否真的是正确的方法 - 对于初学者来说它不是 perl
,因为它无法编译。无论哪种方式,尝试将内容评估为 'parse config' 通常都不是一个好计划 - 它很容易出现令人不快的故障和安全漏洞,因此应保留以备不时之需。
我会敦促您通过以下任一方式以不同的方式进行操作:
写成模块
像这样:
package MyConfig;
# Configuration file for main script
our %config = (
username => "username",
password => "none_of_your_business",
favorite_color => "0x0000FF",
);
然后您可以在主脚本中:
use MyConfig; #note - the file needs to be the same name, and in @INC
并将其访问为:
print $MyConfig::config{username},"\n";
如果您不能将它放在现有的 @INC
中 - 这可能有您不能这样做的原因,FindBin
允许您使用相对于您的脚本位置的路径:
use FindBin;
use lib "$FindBin::Bin";
use MyConfig;
将您的 'config' 编写为定义的可解析格式,而不是可执行代码。
YAML
YAML
对于配置文件来说非常可靠,特别是:
use YAML::XS;
open ( my $config_file, '<', 'config.yml' ) or die $!;
my $config = Load ( do { local $/; <$config_file> });
print $config -> {username};
您的配置文件如下所示:
username: "username"
password: "password_here"
favourite_color: "green"
air_speed_of_unladen_swallow: "african_or_european?"
(YAML 还支持多维数据结构、数组等,不过你似乎不需要这些。)
JSON
JSON
based 看起来很像,只是输入是:
{
"username": "username",
"password": "password_here",
"favourite_color": "green",
"air_speed_of_unladen_swallow": "african_or_european?"
}
您阅读它的方式是:
use JSON;
open ( my $config_file, '<', 'config.json' ) or die $!;
my $config = from_json ( do { local $/; <$config_file> });
使用相对路径配置:
您完全不必担心 @INC
。您可以简单地使用基于相对路径...但更好的选择是不这样做,而是使用 FindBin
- 它允许您指定 "relative to my script path" 并且更可靠。
use FindBin;
open ( my $config_file, '<', "$FindBin::Bin/config.yml" ) or die $!;
然后您就会知道您正在读取与您的脚本位于同一目录中的脚本,无论它是从何处调用的。
具体问题:
From whose perspective is "./" anyway: the Perl binary, the Perl script executed, CWD from the user's shell, or something else?
当前工作目录通过进程向下传递。所以默认情况下用户的 shell,除非 perl 脚本执行 chdir
Are there security risks to be aware of?
任何时候你 'evaluate' 某些东西就好像它是可执行代码(并且 EXPR
可以)都存在安全风险。它可能并不大,因为脚本将 运行ning 作为用户,而用户是可以篡改 CWD
的人。核心风险是:
- 用户在 'different' 目录中,其他人已将恶意内容放入 运行。 (例如,想象 'config.pl' 中有
rm -rf /*
)。也许/tmp
中有一个 'config.pl' 他们 'run' 不小心?- 您
eval
正在编写的内容有错字,并且以古怪和意想不到的方式破坏了脚本。 (例如,它可能会重新定义$[
并从此以后以难以调试的方式扰乱程序逻辑)
- 您
- 脚本在特权上下文中执行任何操作。情况似乎并非如此,但请参阅上一点并想象您是
root
或其他特权用户。
Is this better or worse than modifying @INC and just using a base filename?
更糟糕的海事组织。实际上根本不修改 @INC
,而是使用完整路径,或使用 FindBin
的相对路径。并且不要 eval
不必要的事情。