2

私はperlスクリプト ( myscript.pl) に取り組んでおり、さまざまなモジュールからいくつかの環境変数を次の順序でロードしたいと考えています。

  • defaultSettings.pmと同じディレクトリのデフォルト設定myscript.pl
  • (オプション) ユーザーuserSettings.pmが選択できる別の場所のユーザー設定
  • localSettings.pm(オプション)現在の作業ディレクトリのローカル設定

最初と最後の箇条書きは解決しましたが、2 番目の箇条書きの解決にはあまり成功していません。

myscript.pl

#!/usr/bin/perl 

use strict;
use warnings;
use FindBin;            
use lib $FindBin::Bin;

# defaultSettings always present in same directory as myscript.pl
use defaultSettings;   

# localSettings sometimes present (in current working directory)
eval
{
    require localSettings;
      localSettings->import();
    };

print "Some variable is: ",$someVariable;
exit

defaultSettings.pm

package defaultSettings;

use strict;
use warnings;
use Exporter;

use vars qw($VERSION @ISA @EXPORT);

$VERSION     = 1.00;
@ISA         = qw(Exporter);
@EXPORT      = qw($someVariable
                  );

our $someVariable="default settings";
1;

localSettings.pm

package localSettings;

use strict;
use warnings;
use Exporter;

use vars qw($VERSION @ISA @EXPORT);

$VERSION     = 1.00;
@ISA         = qw(Exporter);
@EXPORT      = qw($someVariable
                  );

our $someVariable="local settings";
1;

私は私が使用できることを知っています

use lib "/home/foo/bar/";
use userSettings;

でmyscript.pl、しかし、ユーザーに編集させることは避けたいmyscript.pl- 主な希望/目標は、ユーザーに myscript.pl.

同じアイデアを実現する他のワークフローを受け入れます:)

4

2 に答える 2

3

Perl モジュールを使用して構成データを保存しないでください。それは彼らが意図したものではなく、あなたが見たように、彼らはその目的に本当に適していません. また、モジュールに実行可能な Perl が含まれているという潜在的なセキュリティ リスクもあります。この Perl は、システムに対してほとんど何でも行うことができます。データは非実行ファイルに保存する方がはるかに優れています。

代わりに、ディスク ボリュームのどこにでも配置でき、Perl データ構造に直接読み込むことができる JSON データ ファイルのようなものを使用します。

あなたの主な問題は、構成データの 3 番目のセットの場所を定義する方法のようです。私にとって最も明白なオプションは、他の 2 つのセットのいずれかに指定する必要があることです。おそらく、現在の作業ディレクトリに保存されているものです。

于 2013-03-18T03:13:40.377 に答える
0

頭に浮かぶ2つのアプローチ：

  • use lib "$ENV{HOME}/bar";ユーザーがホームディレクトリのパスを入力する必要がなくても、そのディレクトリ内の特定のパスを想定することができます。
  • use lib $ENV{MYSCRIPT_CONFIG};ユーザーがその環境変数を設定することを要求したい場合 (ただし、まったく設定されていない場合は少なくとも警告が表示されるため、これは理想的ではありません。代わりに、BEGIN設定されているかどうかを確認してから開くブロックを作成できます-の効果をコードしますuse lib)。

ただし、より基本的な提案を行います。実際に必要なときにuseandを使用していると思います。これらすべてのランダム パスを、ロードする他のすべてのモジュールにも使用されるグローバル モジュール検索パスに追加するのではなく、次のような戦略を検討してください。requiredo

if ($ENV{HOME} && -f "$ENV{HOME}/bar/localSettings.pm") {
    my $file = "$ENV{HOME}/bar/localSettings.pm";
    my $status = do $file;
    die "couldn't parse file $file: $@" if $@;
    die "couldn't load $file: $!" unless defined $status;
    die "couldn't load $file" unless $status;
}

の欠点は、doはるかに冗長なエラー管理です。利点は、モジュール パスに何かを追加する必要がないこと、特にファイルに名前を付ける必要がないこと、および 3 種類の設定ファイルに順番に別々の名前を使用する必要さえないことです。%INCすべての構成のロードを妨げる処理を避けるため。

(もう 1 つの回答も、構成データに Perl モジュールを使用することについて常に 2 回考えるべきであるという点で良い点がありますが、それが非常に良い考えである場合もあります。1 つは、ユーザー構成に本格的なコールバック関数が記述されている場合です私はいくつかのソフトウェアパッケージを持っていますが、その場合はそうです。)

于 2013-03-18T03:17:36.283 に答える