FORFILES.EXEがエラーを出す

日常的に利用しているWindows10の%HOMEPATH%\Documentsのファイル群をdynabook SS SX/15A上に構築しているNetBSD/i386の~/Documentsに同期させる仕組みを構築するために、Windows10側でFORFILES.EXEを利用することにしていました。うまくいくと思いましたが、エラーが出てくるようになってしまいました。

処理中に「エラー: パラメーターが間違っています。」 というメッセージが出て、処理が中断してしまいます。この「パラメーター」というのはコマンドラインオプションの事ではないと思います。では何の「パラメーター」なのか？それが不明なのが困ったところです。これ以上の情報が無いので、何がどのように「パラメーターが間違ってい」るのか、さっぱり分かりません。

エラーを解決する方法が不明なので、代替策を検討する必要があります。当初の目的に立ち返ることにしましょう。そもそもの発想の原点は、Windows10側で更新されたファイルリストを生成させておくという事でした。UNIXであればfindを使うのが素直な解決策だと思いますが、Windows流儀ではどうすれば良いのでしょうか。Win32用に移植されたfind.exe（Windowsには昔からFIND.EXEという名前の、UNIXで言うところのgrepのようなプログラムがありますが、そのことではありません）が見つかれば良いかもしれません。またはCygwinのような環境を構築しておくという方法もあるでしょう。しかし、どうも気が進まないのです。「鶏を割くに焉んぞ牛刀を用いん」と言うか、「木に竹を接ぐ」と言うか、違和感があるのです。

Windows10のFall Creator UpdateからはWSLが利用できるようになりました。WSL内でWindowsのプログラムを起動させることができるようなのですが、逆はどうなのでしょうか？試しに簡単なシェルスクリプトを書いて、Windows側から起動させてみたところ、%SystemRoot%\System32\wsl.exeを使えば、シェルスクリプトを起動できることが分かりました。

しかし問題があって、wsl.exeに渡すファイル名は、WSL環境が理解できるパスになっている必要があるのです。つまり、例えば「C:\Users\FOO\BAR」であれば 「/mnt/c/Users/FOO/BAR」と指定する必要があるのです。またWSLは一応UNIXですので、ファイル名の文字種（大文字と小文字）の違いにも意識する必要があります。

結局、簡単なWindows用スクリプトを介してwsl.exeを使うことにしました。以下の内容を含むcmdファイルを作って使うことにしました。

set CMDPATH=%~pnx1
wsl /mnt/c%CMDPATH:\=/%

WindowsからWSLのシェルスクリプトを呼び出すことにすれば、堂々とfindを使うことが出来ます。これで同期対象ファイルのリストを生成させられれば、後はNetBSD側でリストを読んで、対象ファイルをコピーするだけです。その仕組みは従来と同じなので、たぶん大丈夫でしょう。

考えてみるとWSLというのは不思議な世界です。Windows上でUNIX環境が動くのですが、過去に存在した如何なるものとも違うのです。Win32用バイナリを探してU*IX-likeな環境を作るのとも違うし、Cygwinの環境とも違い、またVirtualBoxなどで仮想環境にU*IX系OSをインストールした環境とも違います。使い道は個人個人で異なるとは思いますが、WSLには可能性を感じます。