まず最初に、４つのファイル foo, bar, *, xxx yyy があるディレクトリがあるとします。(試したい場合は新規のディレクトリで下記のコマンドを実行してください。)
touch foo bar \* 'xxx yyy'
さてここで、ループを使って各ファイルを一つ一つ、コマンドに食わせたいとします。 そのために、こんなループを書いたとしましょう＞
for f in *; do ls -l $f done
それがこんな動作になるシェルは 疲れる から、です。
zsh であれば、デフォルトの設定（ no_sh_word_split かつ no_glob_subst ）で使っていれば、期待通りに４回だけ、一つずつファイルを渡しながらコマンドを実行してくれます。
（なお実行中の zsh をデフォルト設定にリセットするには emulate -L zsh コマンドが使えます）
他にも理由はありますが、これだけでも十分な理由かなと。
読んで下さり、ありがとうございました。
ansible によるサーバー運用管理の自動化が流行っているようですね。管理対象サーバーが沢山有り、なおかつ既存のレシピ（ansible だと module？）が自分の業務に活用できるなら、強力なのでしょう。
ですが世の中には、サーバー一台でも全ての業務を余裕で処理できてしまい、かつ自社の独自アプリ群の運用が主なテーマであるようなお仕事もありまして…
そういうお仕事で、 ansible (に限らず、流行の運用自動化ツール… chef? puppet?) は果たして便利なんだろうか？という疑問が有ったりします。例えば：
みたいなことを思うのです。
かと言って生の shellスクリプトだと（確かにファイル名とかは雑に書けて楽なのですが）、 そもそも shell(bash)スクリプトの弱点として
という問題があります。
その上、管理自動化用の機能を全部自分で書く必要があるでしょう。例えば：
このうち 1, 2 は shellスクリプトの書き方に慣れればある程度は対応できます。 ただ、shell(bash)スクリプトでは複雑なデータ構造のサポートが足りないため、タスクの依存関係の処理までは 手が回らないことが多いのではないでしょうか？
この 3つを一挙に解決する道具として Makefile を使う手もあります。 特に最終的な目標がファイルの作成である場合は、とても有効です。
しかし、Makefile はファイルのタイムスタンプのみに基づいて依存関係を処理します。
ですから例えば /etc/ のあるファイルの中に〇〇が記述されていなければ記述を足す、みたいな処理を書くことは困難です。
つまり、サーバーの設定ファイルの自動書き換えには向かない面があります。
ところで皆さんお忘れですが Tcl という言語が存在します。 Tcl は文字列の扱いに関して shell よりも更に緩くかつ構文を最小限に絞っています。 にも関わらず例外処理や名前空間があり、ある程度複雑なものも書ける、本格的なプログラミング言語です。
ということは、 Tcl に Make に似た依存関係探索ライブラリーが有ったら、サーバー管理の自動化に 使えるのではないかしら？
という思いつきで実験を重ねてきたコードがこちらです。その名の通り wip ですが、やりたいことは伝わるのではと＞ GitHub - hkoba/wip-TclTaskRunner0: WIP: Small task runner library in Tcl. Makefile alternative.
この現在の実験版では、例えば、 webmaster というユーザーと devel というグループのべき等な追加処理を下記のように書けます。 check が検査のコードで、check が false を返した時のみ、 action ブロックが実行されます。 ** は dry-run のマーカーです。タスク定義ファイルの中には普通の Tcl の手続きや変数を定義して使うことも可能です：
#!/usr/bin/env TclTaskRunner.tcl import {file-has} from utils.tcl default target all dependsTasks { webmaster devel } target webmaster check { check-user $target } action { ** exec useradd -s /sbin/nologin $target } target devel check { check-group $target } action { ** exec groupadd $target } proc check-user {user} { # id コマンドの呼び出しても良いですが、ファイルの中身の確認の例ということで… file-has ^${user}: /etc/passwd } proc check-group {group} { file-has ^${group}: /etc/group }
こういう構想にご興味ございましたら是非お話しましょう〜
いまは例えばこういう所を悩んでいます：
target よりも task の方が良い？
(タスクランナーって名乗っているのだから…けど依存関係は target って言ったほうが自然な気がする)ここまで読んで下さり、有難うございました。
この記事は *.pm による Perl のクラス定義を CLI から直接的に試せるようにする開発技法の提案・解説です。
Perl のモジュールを CLI コマンドとしても使えるようにする手法は Modulino (モジュリーノ＝コマンドとしても実行可能なモジュール) と呼ばれます。この記事では私が長年探求してきた Modulino を OOP と組合せて Perl 開発に役立てる方法の、最も基礎となる部分について解説します。 （OO Modulino 技法とでも言いましょうか）
要約すると
--name=value) を new の引数にするというアプローチが良いという考えです。
Modulino とは、 Perl の正当なモジュールファイルであり、 なおかつ端末からコマンドとして実行することも出来るような .pm ファイルのことです。
例えば以下のような（Modulino ではない）普通のクラス定義モジュールファイル A.pm を考えます。
（ここでは説明を簡略化するため use strict; use warnings; を省略します。）
package A; sub new { my $class = shift; bless +{@_}, $class } sub hello { my $self = shift; join " ", "Hello", $self->{name} } 1;
これをコマンド行から試すには、こう書く必要があります。
% perl -I. -MA -le 'print A->new(name => "world")->hello' Hello world %
そこそこ長いですね。初心者に打たせるのは厳しい感じですし、 Perl に慣れた人でも少しダルく感じるのではないでしょうか。
これを Modulino に書き換えてみましょう。 unless (caller) という見慣れない構文が鍵となります。
#!/usr/bin/env perl package A; unless (caller) { # コマンド行から呼ばれた時にしたい処理をここに書く。例えば… print A->new(name => shift)->hello, "\n"; } sub new { my $class = shift; bless +{@_}, $class } sub hello { my $self = shift; join " ", "Hello", $self->{name} } 1;
これなら、コマンド行から即座に実行できます。 ファイル名に shell の補完も効きますし。
% chmod +x A.pm % ./A.pm world Hello world
また、perlデバッガーを呼び出したい時も頭に perl -d を付けるだけです。余計なコーディングは不要です。
% perl -d ./A.pm world
先程の A.pm は unless caller ブロックで A->hello を直接呼び出していました。
しかし大抵のクラスのオブジェクトは複数のメソッドを持つでしょう。 他のメソッドを試したい時は、やはり CLI に長いコマンドを書く必要が生じます。
% perl -I. -MA -le 'print A->new(name => "world")->goodnight'
なら git のようにサブコマンドを取ることにして、
それをメソッド名として解釈してはどうでしょう？つまり
unless caller ブロックに第一引数に基づく dispatch 処理を組み込むのです。
（引数不足のエラー処理は省略します）
unless (caller) { my $self = A->new(name => "world"); my $cmd = shift; # CLI の第一引数をメソッド名に使う print $self->$cmd(@ARGV), "\n"; }
これで任意のメソッド名を呼び出すことが出来ます
% ./A.pm goodnight Good night world
任意のメソッドを呼び出すことは出来るようになりました。…けど、まだ不満が有りますね？
そう、new の引数が name => "world" に固定なのです。これもコマンド行から変更可能にしたい。
これも git のように、サブコマンドの前の --name=value スタイルの引数列を全て new に渡すようにしては
どうでしょう？
unless (caller) { # CLI から渡された --name=value 形式の引数を全て new に渡す my $self = A->new(name => 'world', _parse_posix_opts(\@ARGV)); my $cmd = shift; print $self->$cmd(@ARGV), "\n"; } sub _parse_posix_opts { my ($list) = @_; my @opts; while (@$list and $list->[0] =~ /^--(?:(\w+)(?:=(.*))?)?\z/s) { shift @$list; push @opts, $1, $2 // 1; } @opts; }
これで new の引数も CLI から制御できるようになりました。
% ./A.pm hello
Hello world
% ./A.pm --name=Perl hello
Hello Perl
Perl のクラス定義に unless (caller) ブロックを加えて、
オブジェクトの挙動をコマンド行から簡単に試せるようにする技法の基礎について
解説しました。
OO Modulino には他にも
@INC 調整に FindBin を使った場合に起きる問題とその対処法use fields で宣言しておき、メソッドの引数宣言を my TYPE $self のようにクラス名も書くことで、メンバー変数の typo をコンパイル時に検出する
fields::new($class) を使うことで、不正なオプションを渡されても実行時エラーにするData::Dumper や JSON を使ってシリアライズして出力する
cmd_ などのメソッド名接頭辞を予め決めておく。{..} [..] が現れた場合は JSON として扱う./A.pm <TAB> でメソッド名やオプション名を補完する
zsh completerなどの発展的な話題があります。それらを全て盛り込んだベースクラス MOP4Import::Base::CLI_JSON の話も、機会が有れば書いてみたいと思います。
また、新人教育に Modulino を取り入れる方法のメリットについてはこちらの記事も参考にどうぞ＞
-nle と .pm から始める Perl 入門とかどうかしら？（後編） - hkoba blog
ここまで読んで下さりありがとうございました！
昨年2019の夏頃から libperl-rs というライブラリを作っています（現状では仕事とは無関係の、純然たる自宅研究です。進みも間欠的です）。これは Perl5 のランタイムライブラリーである libperl を Rust から呼び出すためのラッパーライブラリーです。
libperl-rs については、これまでは YAPC Japan 2019 名古屋で発表した以外は、 これといった情報開示をしてきませんでした。
別に秘密というわけではなく、 単に blog を書くことを面倒臭がっていただけで、 github 上には 少しずつ進展を出してはいました。ですが最近、私が前もって現状を整理して公開していれば、誰かさんを困らせなくて済んだのかもなー…と思うこともあり…
ちょっと現状を整理して開示しておこうと思います。
私が libperl-rs で一番やりたいことは、 Perl プログラムの AST (OP Tree) の解析です。 特に、動的に生成されるスクリプトの AST を解析し、その実行前にエラーを検出したり、 Language Server やデバッガーを提供したり…ということが出来るような道を開きたいと考えています。 （そこまでたどり着けるとは言い切れませんが…）
現在の libperl-rs は３つの crate から構成されています。
% tree -L 2
.
├── Cargo.lock
├── Cargo.toml
├── LICENSE
├── build.rs
├── examples
│ ├── 000_perl_parse.rs
│ ├── 001_perl_parse_args.rs
│ ├── 100_scan_ops.rs
│ ├── 101_scan_ops_debug.rs
│ ├── 102_padname_type.rs
│ ├── 103_scan_op_tree.rs
│ ├── 104_enum_op_tree.rs
│ ├── 105_scan_stash.rs
│ ├── 106_scan_allpackage.rs
│ ├── 107_scan_subs_in_a_file.rs
│ ├── 108_scan_subs_in_a_file2.rs
│ ├── 109_scan_subs_intro1.rs
│ ├── 110_call_method.rs
│ └── eg
├── libperl-config
│ ├── Cargo.lock
│ ├── Cargo.toml
│ └── src
├── libperl-sys
│ ├── Cargo.lock
│ ├── Cargo.toml
│ ├── LICENSE
│ ├── build.rs
│ ├── examples
│ ├── script
│ ├── src
│ └── wrapper.h
├── release.toml
├── runtest-docker.zsh
├── src
│ ├── lib.rs
│ └── perl.rs
└── target
├── debug
└── rls
現状では 1., 2. については API はほぼ安定しているのではないかと思います。（改良の余地は有るかもしれません）
問題は 3. の libperl-rs です。 2. のbindgen によって生成された libperl-sys は Perl の C API からマクロを取り去った、裸の API です。しかも threaded 版と非スレッド版の２系統が存在します。それを Rust の層で抽象化し直す必要があります。 私がまだ Rust の修行中であることもあり、一発で正解にたどり着く自信はありません。 とても API が固まったとは言えない状況です。
そのため、現在は主として examples ディレクトリーの下に 実験的なコードを書き、その中で今後 libperl-rs の本体に組み入れると良さそうなコードを eg サブディレクトリーに作り貯めている所です。 皆さんのツッコミをお待ちしております。
今の段階の libperl-rs で出来ることは、どれも B モジュール で (とても頑張れば)出来ることばかりだと思います。
とはいえ、OP Tree に対してパターンマッチが出来るようになりつつあることは、
少なからぬメリットなのではないでしょうか。以下は Perl のサブルーチンの冒頭から
my (...) = @_ に相当する AST を抜き出すための、パターンマッチのコードです。
(少し冗長ですが)
他にも (perl_parse の作る) 静的な OP Tree を調べるコードだけではなく、 perl_parse 後に任意のクラスの任意のメソッドを Rust から呼び出してみるサンプルも、（まだまだベタな書き方ですし不足もありますが）動き始めています（抜粋）。
現段階では github の master を試して頂くのが良いと思います。(crates.io にあるものは、YAPC Japan 2019 名古屋の 時のバージョンです。それ以後の改良部分を crates.io に送るのは、もう少し API が固まってからが良いのかなと…)
私自身の開発環境は Fedora 30 ＋ System Perl (perl5.28) + System Rust (1.42) ですが、 travis-ci 上では Perl 公式 Docker イメージを用いて Perl 5.30〜5.22 での動作を確認してあります。 (発展的な例は threaded build な Perl5.26以上限定です) (libperl-sys までなら、もっと古い Perl でもビルド出来そうな気がします)
ですので、Debian, Ubuntu の上であれば以下の手順で動かしてみることは可能でしょう＞
apt update &&
apt install -y llvm-dev libclang-dev clang &&
curl --proto "=https" --tlsv1.2 -sSf https://sh.rustup.rs > rustup.sh &&
sh rustup.sh -y &&
source $HOME/.cargo/env &&
rustup component add rustfmt
git clone https://github.com/hkoba/libperl-rs && cd libperl-rs
examples/109_scan_subs_intro1.rs を実行してみる（渡したスクリプトの namespace から
my (...) = @_ 形式の引数宣言だけを抜き出すサンプル)
% Z-chtholly(pts/2)% cargo run --example 109_scan_subs_intro1 -- -le '
package Int;
sub foo { (my Int $x, my Int $y) = @_; $x + $y }
'
Finished dev [unoptimized + debuginfo] target(s) in 0.03s
Running `target/debug/examples/109_scan_subs_intro1 -le '
package Int;
sub foo { (my Int $x, my Int $y) = @_; $x + $y }
'`
$0 = "-e"
sub "foo"
preamble!
first array assignment from @_, lvalue = [PadNameType { name: Some("$x"), typ: Some("Int") }, PadNameType { name: Some("$y"), typ: Some("Int") }]
ここまで読んで下さり有難うございました。ご意見お待ちしております！
旧年中に仲良くして下さった皆さん、有難うございました。 今年もどうぞよろしくお願いします。
（以前から構想していたことだけど、実際に）職場の Perl の新人教育のプロセスを -nle と .pm から始めるよう試した結果、それなりの効果を確認できたこと。少なくとも .pm から教えることは現代的には全く問題が無い。ボイラープレートは File::AddInc と M4I の CLI_JSON にまとめる方向で引き続き。
艦これアーケードの秋イベント、なんとか甲クリアを継続できたこと
この記事は Perl Advent Calendar 2019 の 12/5 の記事です。内容は主に職場で Perl を 教える側 の人に向けた、提案です。
昨日の記事は、Perl 屋の新人教育を コマンド行ツールとしての Perl から初めてはどうかしら？という提案でした。
今日の記事は、その新人さんの教育が進んで、コマンド行では収まらず、
エディタ＋ファイルを使いたい規模に進んだ時に、今までどおりに
*.pl の書き方を教え続けるのが良いのだろうか？
いやむしろ、 コマンド行の次は即座に *.pm の書き方を 教えては？という話です。
.pl 飛ばして、 .pm から教えては？案私が *.pm の書き方から教えることをお勧めする理由は、以下の２点です。
*.pm は *.pl を兼ねることが出来る（後述の Modulino）が、逆は違うから。職場にもよるでしょうが、
今の時代に Perl を書くお仕事は、新規開発よりも保守改良のお仕事の方が多いのではないでしょうか。
その保守改良では、既存の業務のコードベースのモジュール群(つまり *.pm)を読み書きする能力が
不可欠です。だとしたら、 *.pl を学ぶことは新人さんにとって回り道なのではないか？
という疑問があるのです。
もちろん *.pl は *.pm よりもプログラミングの際の決まり事が少ないのは事実です。
教育の初期において負荷は少ないほうが良いという意見も分かります。
ただ、その部分はコマンド行の Perl でカバーしても良いのではないでしょうか？
何より、新人教育期間はただ知識を吸収するためだけではなく、
トレーニングのために確保された期間でもあります。
トレーニングは今後の仕事で必要となる作業に対して、その負荷に慣れて自然に動けるように力を
成長させるためのプロセスです。最終的に職場で要求されるのが *.pm であるなら、
その負荷に慣れるトレーニングを早めに始めることが大事なのではないでしょうか？
念のため、 *.pl, *.pm の長所・短所を整理してみます。
.pl の長所・短所*.pl の長所
*.pl の短所
*.pl ファイルをただ書いても、require, use で使えるモジュールにはならない。
*.pl の中の関数を他のファイルから呼び出せない。*.pl で書いたコードは単一の用途・文脈でしか役に立たないコードになる。.pm の長所・短所*.pm の長所
require, use, perl -Mモジュール名 で他のプログラムに読み込める*.pm の短所
*.pl の時よりは）真面目に考える必要が生じる。（拡張子も .pm固定）*.pm を実行可能にするには、 Modulino の書き方を覚える必要が有るでは具体的に、新人教育でモジュールの書き方をどう教えればよいのでしょうか？ 私は (Modulino = モジュリーノ) と呼ばれる書き方を使って、 スクリプトとしても実行可能なモジュールを書いてもらうことを提案します。
最初のモジュールは、おもちゃでも構いません。 むしろ怖がらないで済むように、おもちゃで始めるのが良いのではと思います。
例えば *.pl で最初に教えてきたのが print "Hello world!\n" なら、
同じことを実行可能なモジュールで教えれば良いでしょう。
練習ですから、ファイル名も細かいことは言わないで、ストレートなものが良いでしょう。
#!/usr/bin/env perl package Hello; unless (caller) { print "Hello world!\n" } 1;
あとはこのファイルに実行 permission を与えて、動かすのみ。
% chmod a+x Hello.pm % ./Hello.pm Hello world! %
モジュールとして読み込む場合はこうなります。
% perl -I. -MHello -e0 %
ただこれだと何も起こらなくて、嬉しさが伝わりませんね。
なので、教育の中で『関数が必要な題材』が出てきた段階で、初めて作る Perl の
スクリプトファイルとして *.pm の書き方を教える、というのが良いのではないかと思います。
上で挙げた例の Hello.pm に use strict; use warnings が無いことを見て、
凍りついた人もいるかもしれません。業務に耐えるレベルのモジュールを書ける人になってもらうためには、
勿論、避けて通れない話です。この点は教育課程の練りどころで、私も現在、研究の最中です。
皆さんと情報交換していけたら有り難いです。
一つ言えるのは、コマンド行 Perl の教育と *.pm ファイルの教育は
必ずしもスパッと二期に分ける必要はないのではないか？ということです。例えば
コマンド行で課題をしてもらっている中で、新人さんが変数の typo で苦労をし始めていることを
観測したら、その時点で *.pm ファイルの書き方に教育をスイッチして use strict と my を教える、というようにです。また逆に、新しい機能を紹介する時は、まず最初にコマンド行で実演してみせる、という手も有りえます。
多人数の同時教育では難しいかもしれませんが、ペア・プログラミングで徒弟的に教育を進められる場合は、 有力な方法ではないかと思います。（教育プロセスにもTMTOWTDI、なんちゃって…） （Perl教育すごろくとかあると面白いかも…〇〇に詰まったら☓☓を教える、みたいな）
職場の新人さんに向けた Perl教育で、コマンド行ツールとしての Perl を教えた後は
即座に Modulino で *.pm の書き方を教えるのはどうでしょう？という提案でした。
（実は Modulino の書き方に関してはFile::AddInc で @INC を調整する話とかオブジェクト化とサブコマンドの話とか use fields でオプションを表現する話とか引数/出力のJSON標準化の話とかネタは色々有るので、アドカレの空きが有ったら書くかもしれません…書けないかもしれません…＞＜）
Perl Advent Calendar 2019, 明日の担当は, AnaTofuZ さんです.
この記事は Perl Advent Calendar 2019 の 12/4 の記事です。内容は主に職場で Perl を 教える側 の人に向けた提案です。
（今から仕事で Perl を学び始める人は、多分 Linux/Unix 環境に関わる人であろう、と想定しています。違ったらごめんなさい。）
皆さんは職場の新人さんに Perl を教えるとき、初めにどんな形式でプログラムを書いてもらっていますか？
普通は何らかのエディタで foo.pl, hello.pl のように *.pl ファイルを作ってもらって実行、ではないかと思います。この方法は、使い慣れたエディタが有る人には最も安心感を与える方法でしょう。
ですが、この方法には二つの弱点があるのではないでしょうか？
$_ などの特殊変数や、その省略法則（ex.デフォルトの m// の対象、split の第２引数、 -X テストの対象…）を教える切っ掛けが乏しい*.pm 形式のモジュールの書き方が先送りされるそして何より、 今さら、 Perl を学ぶメリット を語る力が弱いのではないか？と私は思うのです。 1990年代ならともかく、現代では Perl は Python, Ruby, PHP そして JavaScript と 強く比較しながら使われる時代です。今さら何故 Perl? という問いに答えを用意してあったほうが、 学ぶ人も意欲を持ちやすいのではないかしら？という考えです。
その意味で、私は、最初に教える Perl はコマンド行での perl -nle … が良いのではないか？
と考えます。何故なら、 コマンド行ツールとしての Perl の強さは、2020年代を迎える今でも十分な輝きを保っているからです。幾つか挙げるなら、
つまり、コマンド行ツールとしての Perl から始める理由は、簡単に学習を始められる上に、努力と得られるメリットの比率も抜群だからです。
また、Perl を学ぶ時の難所である $_ などの特殊変数やその省略法則を教えるという点でも、
コマンド行スタートにはメリットが有ります。何故なら、それらが
ワンライナーを少しでも短く楽に書けるように設計された、lwall からのギフトだからです。
なのにコマンド行を全く避けてしまうと、その短い記法が分かりにくさ・読み難さの元凶、
害悪にしか思えなくなるでしょう。説明する側も言い訳がましくなり、辛いところです。
他にも副次的効果を何個も挙げられます。
perl -w の説明も導入しやすいperl -d のデバッガに馴染む切っ掛けにも繋げやすい
（ただし Term::ReadLine::Gnu の導入を推奨）use strict の意義を伝えやすくなる。BEGIN {}, END {} を教える切っ掛けも作りやすいこの方法の弱点は、学習の記録を残すことが難しいことです。 学習の効果を定着させるには、学習者が学んだことを容易に振り返って復習出来ることが大事です。 しかしコマンド行は一過性の側面が大きいため、そこを不安に（不安定に）感じる人もいるでしょう。
これについては、以下の対策が有りえます。
history -w, fc -W)を初期に教える。
B::Deparse を使いながら冗長な（省略を廃した）
記法も教える。それをスクリプトファイルとして残し、これを git に保存する。あとひとつ難しいかもしれないのは、コマンド行での Perl の使い方は環境（組織、文脈）に特化する面が大きく、 汎用の教材を作りにくい、かもしれないことです。例えば業務の副次的なプログラムのエラーログから 情報を抜き出して DB に投入するとか…それが一般的で頻出する問題なら、既に専用のプログラムが 作られていたり、予め構造化してログを吐くことが出来ているはずです。 （もっと良いツールがあるのに何で自分で書くの？と言われると…教える時の言い訳が増えますね…内容次第ですが…）
なので、教育のためのシナリオと、そこで使うデータセットの準備が、最も 手間取る所になりそうです。
（適切なツールが既に存在しても、それを探し出すのに何十分もかかるなら、自分でさっとスクリプトを書いたほうが早い、というケースの話も、しても良いかもしれません）
とはいえ、既存の教材も無くはないので、例えば↓この辺りから 題材を抜き出しつつ教えるのも良いかもしれません。
あと、同じくフィルタに向いた言語のご先祖様であるプログラミング言語AWKの本からも例題を拾えるかもしれません。
Perl 屋の新人教育、最初はコマンド行の Perl から初めてはどうかしら？という提案でした。
では、学んだコードをファイルにしたくなった時、 *.pl に入れるのが良いのだろうか？
いやむしろ、最初から *.pm で学ぶと良いのでは？
そういう話を明日の後編記事に書きます。