上がローカル、下がリモートのファイルリストだ。項目
/1)緒言/ 2)動作環境/3)WebDAVサーバ/4)cadaver/5)DAVExplorer/6)Eldavは失敗/7)PerlDAVのインストール/8)俺スクリプトを作ってみよう/9)caveman.plのコンセプト/10)コマンド体系/11)ローカルディレクトリ内を移動する/12)リモートファイルリストの簡略化/13)リモートのパスを変更する/14)謎なリモートからのget/15)すでにあるリソースに上書きする/16)η版・・・くらいかな。/17)全然仕上がってないけど仕上げはGUIツール/
caveman.pl コード/ cavemangui.plコード
記事で紹介されたWebDAVクライアントツールをIntel版Solaris9に導入する試みを行った。
とりわけPerlDAVについては、添付のスクリプトdaveと記事に掲載されたサンプルスクリプトを参考に、daveをもっと単純化したスクリプトを自分で作ってみることにより、PerlDAVに対する理解を深めた。
今回は、非常に興味を引かれた特集はあった。なぜ具体的に書かないかというと、ヘンに書いてポータルとかでヒットしちゃって、その情報が知りたくてアクセスしたのにそれをやらなかった言い訳を読まされた、なんてことになったら申し訳ないと思うからである。だがその実験対象となるハードウェアはわたしにとってはある特定のプログラミング言語の実行環境の研究に用途がある（そろそろウザくなってきたぞこの抽象化）ので、つまり今度こそ失敗しておシャカにするのはさすがにヤバいとビビった。ブッちゃけ。
一方、現在我が家にはWebDAV共有によるファイルサーバが実働中だ。しかるにいくつかのホストでは、これにクライアントアクセスする環境が整っていない。
実は、そのWebDAVサーバはWindowsなのである。だから、Windowsクライアントは、うちの場合はWindows共有で問題ない。
問題はUNIXクライアントだ。SparcマシンBladeは、Gnomeデスクトップ環境がすんなり動くので、NautilusによってGUIGUIとファイルのやりとりが可能だ。
それができないのが、Gnomeデスクトップ環境との相性が深刻によくないチョト前のIntel版Solaris9(12/02)。
及び添付のWindowsアクセスユーティリティは仕方なく使っていたが実はかったるくてかったるくてしょおがねえリナザウことLinux Zaurusである（本題に入ったので具体的に言及する）。
今回の記事ではコマンドラインベースからPerlのモジュールまでいろいろなWebDAVクライアントが紹介されていたので、さっそく試してみることにした。
本編ではIntel版Solaris9における実践結果を報告する。Zaurusへのクライアント導入については、(2)に報告する。
今回のUNIX USERモニター報告に際してはいろいろなことを学んだり発見したりしたが、予想だにしなかった発見は、近年のインテルアーキテクチャの高速化は、UNIX系OSといえども載せるマシンの新旧で天地の開きがある、ということだった。
前回のGlobus Toolkit2.4導入に際してのことだ。そこで、「もっと速いインテルマシンにインテルソル9を入れて見てエッ」とわたしのような者が思うのも無理ないことであった、というか思わない方が無理であった。そこで新たな構成でマシンを組み上げた。いろいろなマシンをいろいろな構成に組んではバラしているので、もうどれがのに子何号だかわからなくなってきているが、一応「のに子2号」としておく。今回の構成をここに示す。
CPU: Intel Celeron 2.7GHz
RAM: 1024MB
グラフィックボード: ATI Radeon 7200
LANボード: Intel pro +100
マザーボード: Intel BOXD865PERLK（どこまで書けばいーんでしょーかッ？）
CPUは、パソ屋さんで「この2.6Gをください」と言ったら「お客さん本日2.7が入荷しましたよ」と言われ、「グッ。ゲッ。でもま、いいですこれで」「でもお値段もそう2.6Gと変わりませんよ」「グァッ。ギャッ。まあたかだか0.1の差にこだわることもないわね、じゃあ2.7くださいッ」と言って買ってしまったもので、その後しばらく雑誌のハードウェア情報にも2.6までしか載らないでいたのに非常に気を良くしたりしたものである。
グラフィックボードはSolaris9との相性を考え抜いての選択である。無論考え抜いてくれたのはわたしではない。
LANボードもSolarisとの相性では実績のあるPowerEdgeの、オンボードではなく挿さって出荷されてきたそれを引っこ抜いたものである。
マザーボードは「ヤだよインテルなんてしろーとくせーの」という夫にわたしが「でもホラ政治は自民野球は巨人ハードはインテル、やっぱなにかと安心じゃない、オンボードのLANももしかしたらSol9で使えたら超もーけものじゃないの」とけしかけて買ったのだが、やはりオンボードのLANは対応せず上記のようなことになった次第である。
このような環境にSolaris9をセットアップした。はええ！あっち向いて尻など掻いてる間に（掻くなヨ）もうログイン画面だ。開発ツールNetBeansとか、各ウィンドウがペッペッペッと音を立てそうな勢いで貼られて行く。そして潤沢なメモリ。これならGnomeも支障なく動くのでは？そうそうちゃんとパッチを当てればきっと万全よ！とSunのサイトから推奨パッチ詰め合わせをダウンロードしてきて充てた。この作業も速い！Windowsのサービスパッチ3とかよりもしかしたら速いかもしんない！そのあとのGnomeのインストールも速い！Gnomeの起動も！だがさっそくパネルのターミナルアイコンをポチっとやったら一瞬画面が真っ暗になりシステムは再起動した。
いくら速くても2度も3度もやり直したいものではない。泣く泣くCDE環境に戻した。そしてWebDAVクライアント環境構築の必然性がさらに高まったのであった。
WebDAVサーバマシンとその設定・稼働状況については、別ページにその基本的な説明をさせていただいた。
ここでは概略を述べると、稼働マシンはThinkPad T21、OSはWindows 2000 Professionalである。
Apache2.0はWebDAV共有のためだけに導入し、Webページの公開、といっても家庭内だけだが、はTomcatの8080ポートモロ出しという、一風間抜けな状況である。
http://serveraddress/unixshare/ というのがWebDAV共有のルートディレクトリで、読み書きの制限は全くない。これも外部に公開しない家庭内LANだからこその設定であることをお断りしておかなければならない。ホントは家庭内だからって安心してちゃいけないんだろうけど〜。
cadaverは全く問題なくセットアップされ、サーバへの接続やファイルの転送にも問題は見られなかった。cadaverはむしろzaurus SL-C760のほうにインストールして盛り上がったのでそちらを参照いただければ幸いである。
セットアップ・動作問題なし。日本語ファイル名は最初から使おうとも思わないので試していない。だがファイルの送受信はいいのだがディレクトリをまるごととなるとやり方がわからなかった。あるいはできないのか？
これはSolarisではうまく動作しなかった。だがLinuxではちゃんとできた。ク〜ッ（カビラさん風）。だが単にわたしがEmacsの知識に乏しいからかも知れない。それはわからない。
ndの導入までは問題なかった。
対象としたのは、Solaris9セットアップ時にコンパニオンCDからパッケージインストールしたemacs-21.2である。opt/sfw/配下にインストールされている。
解凍した eldav.elとvc-eldav.elの両ファイルを、アプリケーションが必須でロードしてくれる/opt/sfw/share/emacs/site-lisp
フォルダに入れた。
それから自分のホームで.emacsファイルを作り
(require 'eldav)
と記入してセーブ。
emacsを立ち上げるが、ファイルのオープンやセーブの先にWebDAVフォルダのURLを指定すると、見つからないエラーが出る。
.emacsファイルがちゃんと読まれているかどうか確かめるために、(requre 'eldab)と違えてみると、起動時にちゃんとeldabなんて知りませんと出るので、これは読まれていることがわかる。
Red Hat Linux 9を入れたHDDにガチャリと差し替えて、やはりプレインストールのバージョンも同じemacs-21.2（こちらのプレフィクスは/usr/）に対して全く同じ作業をしたところ、ちゃんとWebDAVフォルダにアクセスして読みも書きもできた。emacsとかxemacsとか使うたびにチョとウザく思うあのニョロツキのバックアップファイルまでWebDAVフォルダに生成されている。
やっぱりSolarisだからダメなのかな。なんかくやしー。でもemacsなどを制するにはlispなどについてずいぶん勉強しなければならないようだ。今回はあきらめ〜。
さてこれこそはわたしがちょっといじろうかと舌なめずりしていたヤツだ。
SolarisでMakefile.PLを使ってインストールする場合は、OSに標準でついているPerlのConfig.pmについて、cc用からgcc用に修正を加える必要があるのは、わたしももうだいぶやった。それをやる。
それから必要なライブラリの導入である。LWP及びXML::DOMをCPANからインストールする。
LWPのインストールは問題なく行ったようだ。
だがXML::DOMのインストールは最初失敗した。理由は、expatというツールがSolarisにインストールされてなかったからだ。
きっと、Linuxなどには、当たり前のようにインストールされているんだろうな・・・いいモン。それでもSolarisが好きなんだモン。
XML::DOMの作者様だろうか、親切にもexpatの入手先をエラーメッセージ中に紹介してくださっている。
http://sourceforge.net/projects/expat/
へ行って、expat-1.95.6.tar.gzをもらってくる。解凍して./configure, make make installで問題なく行った。
だが、ここで再びCPANにつないでも、XML::DOMはup to dateですと言って終わる。どうも自動インストールは一回だけ、あとは自分でヤレというらしい。どっちみちパスオプションを指定する必要から、自分でやらなきゃいかんかったからいんだけど。
さて、自分でヤレってどーするのか。CPANからのインストールは、rootで行う。で、rootのホームに.cpanというディレクトリができている。.cpan/build/の中に、自分でインストールする材料が揃っているのだ。
しかし・・・いろいろある。これのインストールにはあれが必要てな具合でつながっているんだろう。さて、何を自分でインストールすればいいのか？
ヒントはこの不完全な状態で、今回の本体HTTP-DAV-0.31をインストールしてみると出てくる。Parserというモジュールがない、と言われた。確かに.cpan/build/XML-Parser-2.34というのがある。そこでここのディレクトリに入って
perl Makefile.PL
とやったところ、「expatがないんで指定のサイトから取って来い」とのお言葉をいただいたというわけだ。
そこでexpatを入手してから、もう一度やってみる。すると
「やっぱだめっスね。ホントに入れたのあんた。だったらどこに入れたか具体的に教えてくんない（意訳・のに子）」
というようなことを言われる。じゃあ教えてやるゼ。ていうかちゃんとパスの指定方法を指示してくださっているので従う。確か、
perl Makefile.PL EXPATHLIBPATH=/usr/local/lib EXPATINCLUDEPATH=/usr/local/include
だった。間違えてもダイジョブ。入力間違えると「そーじゃねえって、こうだよこう」みたく教えてくれる。
するとエラーは出なくなり、make, make installでXML-Parser-2.34は無事インストールされた。
そうして、HTTP-DAV-0.31も無事インストールされた。と思う。もしだめなら.cpan/build内にあるモジュールをカタパシから入れて見ましょうか（いい加減だ・・・・）
ちゃんとインストールされたかどうか試すために添付のプログラムdaveというものを試してみた。それはHTTP-DAV-0.31/bin の中にあった。モジュールのインストール時にどこかに振りまかれるわけではなさそうだ。ちょっと謙虚かも。ちゃんと起動してファイルのゲットやプットなどできた。
さらに記事中に呈示されたサンプルスクリプトのファイルパスを自分なりに書き直して動かしてみた。ちゃんとファイルが所定の場所にプットされた。すげえ。おまけにスクリプトの中身は、オブジェクト指向な感じでものすごいわかりやすい。
さてdaveをもう少しいじってみる。これはすごい。ファイルだけでなくディレクトリレベルでのまるっと送受信ができる。最近はコマンドラインの操作にもだいぶなれたわたし、「これを使えばもうノーチラスはいりません、終わり」でレポート終了してもいいくらいだ。
だがそれでは面白くない。せっかくちったあかじったPerlだ。著者 宮本さんもスクリプトの作成に挑戦していただきたいとおっしゃっている。daveに似た機能を有する自分なりのスクリプトを作成してみよう。
名前はdaveに似ているがもっと原始的でかなりダサいかも、という意味を込めて、caveman.pl だ！
さてこれから作るcavemanの構成を考えよう。必要なのは、
1.ローカルディレクトリの中をうろうろする。
2.リモートディレクトリの中をうろうろする。
3.ファイルの送受信元・送受信先のパスを取得する。
4.ローカルからリモートへ、ファイルやディレクトリをプットする。
5.リモートからローカルへ、ファイルやディレクトリをゲットする。
というところだ。
我が家の場合ファイルサーバのファイルとはつまりバックアップと、複数マシンで処理するファイルの一番新しいっていうか使えるヤツである。だからそれほど頻繁にあっちゃこっちゃのファイルをあっちゃこっちゃへやりとりするわけではない。プログラムを簡単にするために、まずファイルの送受信元及び送受信先を決めてから、ファイルやディレクトリの名前だけを引数に送受信を行うことにした。
上記のような操作をコマンドから行うことにする。このようなものを考えた。[]内は引数である。
ローカルディレクトリ中コマンド：
cd [dirname] ディレクトリdirnameへ移動し、その配下のサブディレクトリ・ファイルを表示する。
cd .. ひとつ上のディレクトリに戻る。
local 今いるディレクトリの情報を再表示する。
put [component] componentという名前のディレクトリまたはファイルをリモートにプットする。
リモートディレクトリ先コマンド：
open WebDAV共有フォルダのルートディレクトリに接続し、サブディレクトリやファイルを表示する。。すでにサブディレクトリにいる場合はそこのサブディレクトリやファイルを再表示する。
open [subdirectory] サブディレクトリに降りる。
open .. 一つ上の階層に戻る。
get[component] componentという名前のディレクトリまたはファイルをローカルにゲットする。
となると、スクリプトの一番最初の仕事は、コマンドを受け付けることだ。
for(;;){
print(">");
$word=<STDIN>;
chomp $word;
if($word eq "exit"){
print("bye!\n");
exit;
}
@words=split(/\s/,$word);
$com=$words[0];
$fd=$words[1];
if ($com eq "cd"){.......}
elsif ($com eq "open"){.......}
elsif ($com eq "put"){.......}
elsif ($com eq "get"){.......}
}
という無限ループにすればよいだろう。
起動すると
>
というプロンプタが現れるので、たとえば
>cd nonisubfolder
みたいにコマンドを打つと、cd とnonisubfolder が空白をデリミタに分割され、それぞれ$comに"cd"、$fdに"nonisubfolder"が代入される。今は$com
eq "cd"だからローカルディレクトリを移動する処理をする・・・というわけ。
daveのスクリプトを見たら、ディレクトリの移動とファイルリストの表示はシステムコマンドcdやlsを利用していた。わたくしはそっちのほうがむしろよくわからないので、Perlのファイルハンドルを使ってしまった。
移動先のディレクトリ名は、上のコマンド処理の部分で$fdに相当する。
$dir をローカルディレクトリの相対パスとする。スクリプト起動時のデフォルトはマイホームディレクトリ、/export/home/noniko にしよう。
cd /export/home/noniko みたく、絶対パスで入力した場合は、$fd=/export....と、文字列の最初が"/"になるので区別がつく。この場合は全置換。
$dir=$fd;
そうでなければ、相対パスと解釈して
$dir.="/".$fd;
と、それまでの絶対パスに追加する。
「ひとつ上の階層に戻る」ためには、$fd=".."としている。この場合は今の$dirから一番最後のパスにあたる文字列を取ればいいのだが、それスマートなやりかたがよくわからないので一度バラバラにして、最後の項の一歩手前まで組み直す方法を採った。
@comps=split(/\//,$dir);
$length=@comps;
for($i=0; $i<$length-2; $i++){
$predir .= $comps[$i]."/";
}
$dir=$predir.$comps[$length-2];
ただし、ルートまで来てしまうと、$dirは無を返しエラーとなる。それを避けるために
if($dir eq ""){
$dir="/";
}
そして、
cdlocal($dir);
と、$dirを引数にサブルーチンcdlocalを実行する。それはこういうものだ。
sub cdlocal{
@cdfil=();
@cddir=();
opendir (DIR,$dir);
while ($fname=readdir(DIR)){
if ($fname ne "." && $fname ne ".."){ // "."とか".."は表示しない
$rname=$dir."/".$fname;
#ここで取得された名前は相対パスっていうかただのファイル名である。
#しかるに、以後のファイルテスト演算子等の適用は、絶対パスに対して行われるべきである。
#なぜなら、それらの処理は、絶対パスかもしくは
#このスクリプトファイルの存在するパスからの相対パスに対して、行われるからである。
#あっちゃこっちゃディレクトリを動くとなにが何の相対パスなのかわからなくなるから、
#絶対パスにしておいたほうが、絶対確実だ。
#最初、それがわかんなくて、あるはずのファイルが存在しないとか言われたりして、
#腐ってんのかこのPerl！とか思った。ラリーさんごめんなさい。
if(-d $rname){ #ディレクトリなら、ディレクトリのリストに。
@cddir=(@cddir,$fname);
}
else { #ファイルなら、ファイルのリストに。
@cdfil=(@cdfil,$fname);
}
}
}
closedir(DIR);
#ファイルハンドルはさっさと閉じて、ゆっくり表示する。
foreach(@cddir){
print($_."/\n");
}
foreach(@cdfil){
print($_."\n");
}
}
リモートディレクトリへの接続そのものは$d->openコマンドでよさそうだ。だが、接続先のファイルリストの表示は？
daveにならって、まずこんな処理をさせてみた。
$d->open(-url=>"http://serveraddress/unixshare".$workdir);
my $resource=$d->propfind(@_);
if ($resource) {
if ($resource->is_collection) {
$rp=$resource->get_property('short_ls');
}
}
出てきた結果はこんなものだった。
Listing of http://hostaddress/unixshare/
./ Oct 12 19:05 <dir>
.DS_Store 6148 Sep 30 14:44
davtest/ Oct 13 13:22 <dir>
noniko/ Oct 10 15:24 <dir>
share/ Sep 25 09:59 <dir>
usako/ May 18 15:01 <dir>
長すぎ。あと、もしこれらのうち特定のファイルをどーとかしようとした場合、ここからディレクトリ名やファイル名だけをどうやって取り出すか？
出力オプションを調べてみたのだが、よくわからなかった。一方、この出力はでかーいひとつの文字列であることがわかった（やっぱ太い。太いぞPerl）とすると、とるべき道は一つしかない。
$rp=$resource->get_property('short_ls');
@rps=split(/\n/,$rp); #一行ごとに分解
foreach(@rps){
if(/^\s+/){ #行頭にスペースがあればそれをとる
$_=$';
｝
/\s+/; #ファイル・ディレクトリ名の直後の空白が認識されるであろう。
$_=$`; #その空白より前の部分、すなわちファイル・ディレクトリ名。
print $_."\n";
これでスッキリした。ディレクトリかファイルかは、末尾が"/"であるかどうかで判断できる。
というのは実はちょっと甘くて、このままでは最初の「Listing」というのまで出てしまう。あと「./」というのもここでは必要ないはずだ。実際のスクリプトではこの0行目と1行目はすっとばすようにしたので詳しくはそちらを御覧いただければと思う。
PerlDAVでは接続先の変更にはcwdというメソッドがあるらしい。やってみたのだがどうもうまくいかなかった。それより、新しい接続先としてopenしちゃったほうが簡単みたいだ。コマンドを
>open nonifolder
みたいにするので、$com="open", $fd="nonifolder" となる。
リモートのディレクトリは$workdirという変数にし、デフォルトでは空である。つまり指定しなければunixshareフォルダのチョクへ行くわけだ。で、
$workdir .= "/".$fd;
と追加していって、
$d= new HTTP::DAV;
$d->open(-url=>$url.$workdir);
my $resource=$d->propfind(@_);
・・・・・と、上記のごとくリストを出させる。
一つ心配なことがあるのだが。PerlDAVで接続を閉じるメソッドってないの？
一応、一回ずつ初期化してることになるから、ダイジョブなんだろうか。
何度も新しいパスに接続してるうちに、リソースがフンづまりとかにならなきゃいいんだけど。でも今のところそういう問題は生じていない。
こうして、ローカルディレクトリと、リモートディレクトリのパスを設定することができた。
あとはファイルのputとgetである。
putは非常に簡単だった。重ねて言うがファイル名でもディレクトリ名でもいい。最初ディレクトリ名でもいいことがわからずに結構複雑なコードを組んでからそれに気づいて呆然とした日曜の夜とかあったが、できないと思っていたものができるとわかったのだからいい。
$localrootdir=$dir."/".$fd;
$remotetarget=$url.$workdir;
print ("Local directory:".$localrootdir."\n");
print ("Remote target:".$remotetarget."\n");
$d= new HTTP::DAV;
$d->open(-url=>$url.$remotetarget);
$d->put(-local=>$localrootdir, url=>$remotetarget);
問題は、上書きってのをこの状態ではできないらしいことだ。エラーになる。だからリモートから古いファイルを削除するdeleteメソッドを併用することになる。それについてはgetの場合と一緒にあとで述べます。
ところが、同じ方法をgetに適用したら、妙なことが起こった。
$d->get(-url=>$remotetarget, -to=>$localrootdir);
とした場合である。tomcatの中のウェブモジュールとかの、わりと複雑なディレクトリ構造のものをこれでゲットしようとしたら、中身が空のディレクトリ群が完璧な構造でローカルに書き込まれた。
？
アクセス権の問題とか、ファイルパスの設定間違いなら、ディレクトリだけが取得できてファイルはダメということがあるのだろうか？
階層の問題なら、ディレクトリの中にあるサブディレクトリが正確にコピーされるのはなぜなのか？でも中身は空〜。
調べて見たがわからない。だが、daveではいとも簡単に任意のディレクトリを、中身が詰まったままリモートからゲットできる。スクリプト的な違いと言えば、一つしか見あたらなかった。それはdaveでは、
$d->get(-url=>$remotetarget, -to=>$localrootdir, -callback=>\&cb);
そして、スクリプト中にsub cb というサブルーチンが確かにあった。なんだか複雑な内容だが、どうもわたしにはいわゆる進行状況を呈示する機能のようにしか見えない・・・
だが、とりあえず他に方法はない。daveからそのサブルーチンの部分をまるっとコピーして自分のスクリプトの最後に置いた。そうして、ゲットのメソッドを上のように書き換えた。
できた。ためしにcocoonbakというフォルダをゲットしてみたら
Transferring http://serveraddress/unixshare/noniko/cocoonbak/web.xml (10896
by
tes):
[############################################################] 10896 bytes
get http://serveraddress/unixshare/noniko/cocoonbak/web.xml (success)
Transferring http://serveraddress/unixshare/noniko/cocoonbak/sitemap.xmap (630
04 bytes):
[############################################################] 63004 bytes
のような表示がダ〜と現れて、ちゃんとファイルの詰まったディレクトリが完全にローカルにコピーされた。
なんで？
ま・・・いいか。ナスカの地上絵の話もあることだし、原始スクリプトcaveman.plが高度文明スクリプトdaveの助けを借りることもあるだろう。
getにしろputにしろ、すでにリソースがある場合はエラーになる。今まではWebDAVに簡単に接続できるWindowsなどの助けを借りて、そっちでチマチマ削除しては実験を繰り返していた。だが最終的にSolarisのCDEから全部できなければ意味がないとまでは言わないがカッチョ悪い。
すでにリソースがある場合は、もとのそれを削除してから送受信を行えばよい。だが黙って削除するのも危険なので一応確認してから、ということにしよう。
putの場合。リモートのリソースを削除するのは、ディレクトリだろーがファイルだろーがPerlDAVのメソッドでラクラクできる。
my $oldremote=$d->propfind($fd); #指定したリソースを調べる
if($oldremote){ #すでにある場合
print("Overwrite ".$fd."? [y/n]");
$overwrite=<STDIN>; #入力を促す
chomp $overwrite;
if($overwrite eq "y"){
$deletetarget=$remotetarget."/".$fd ;
print "deleting ".$deletetarget;
$d->delete(-url=>$deletetarget, -callback=>\&cb); #これでオッケーなのだ
$d->put(-local=>$localrootdir, -url=>$remotetarget,-callback=>\&cb);
}
}
getの場合。階層のあるディレクトリを全削除する方法、Perlでコードを組んでみたんだけどなんだかうまく行かなかった。多大な時間を費やしたあげく結局システムコールに頼るしかなかった。最初から頼るべきだったと後悔した。
$oldlocal=$localrootdir."/".$fd; #ローカルのファイルシステムは絶対絶対パスで行こう
if(-e $oldlocal){ #存在するなら
print("Overwrite ".$fd."?");
$overwrite=<STDIN>;
chomp $overwrite;
if($overwrite eq "y"){
print "deleting ".$oldlocal."\n";
if(-d $oldlocal){
$done=`rm -r $oldlocal` #これっきゃないよモ〜
}
elsif(-f $oldlocal){
unlink($oldlocal); #こっちはperlのメソッドです
}
$d->get(-url=>$remotetarget, -to=>$localrootdir, -callback=>\&cb);
}
こうした次第で、何とか俺スクリプトcaveman.plをデッチあげてみた。
これまでの スクリプトの全文と、実行の様子を別ページに示す。
途中、ファイルパスを表す変数で「/」が一個余計にくっついているようなところもある。幸いファイルパスとして許容してもらえたようだが、処理を繰り返すうちにどんどん増えていったりすると困るので、どこが悪いのか確かめなければならないのだが、実はまだ突き止められていない。
また、一度完成したと思っても、処理を繰り返したりディレクトリを行ってまた戻ったり、絶対パスを使ったり相対パスを使ったり、ちょっと条件が違うとエラーになったりする。特にローカルディレクトリの移動もディレクトリ削除で降参したようにシステムのlsやcdコマンドを使ったほうがよかったのかなという気持ちが一時間ごとに強まってはいるが・・・まだベータ版ていうかガンマ版ていうか・・・ギリシャ文字のアルファベットってよく知らないけど、イータ版くらいじゃないかと思う。でも作ったスクリプトファイル自身をサーバにプットしてちょっと嬉しかった。
コマンドラインベースのスクリプトcaveman.plは上記のごとくまだ全然仕上がっていないのだが、にもかかわらずこれをGUI化してみた！
といっても、ドラ・ドロのような高度なワザまではいかない。ただローカル・リモートそれぞれについてファイルリストを表示して、選んでポチっとなでget, putが行われるという程度だ。進行状況やエラーなどの出力はターミナルに出るようにしたままだし。
Perl/Tkを使用した。見た目はこんな感じである。
上がローカル、下がリモートのファイルリストだ。
以上、ひさしぶりにPerlを本格的にやってその太っ腹に感謝したり黙って無を返すそっけなさを恨んだりしながらも、コマンドラインベース及びGUIベースのWebDAVクライアントツールを自分で作ってみた。とくにGUIベースのはマジでこの先使えそうだ。のちIntel版Sol9のアップデート版買って標準デスクトップ環境がGnomeになったとしても使ってやる決意だ。