おれのIT日記
2024/12/04 (水)
QXエディタ
Sambeサーバへ新規作成できるが上書きできないことがある
我が家のLinuxサーバ"PM-Express5800"ではSambaを動かしてファイルサーバとし、狭い家の中の他のPC複数台から読み書きしている。
各PCは、Windows8.1/10/11と、Linux Mint 19/21、LMDE 6、MX Linux21.3/23.4などで稼働する。デュアルブートが大好きなので、1台に３つのLinux、なんてのもある。VMwareも好きなので仮想マシンも多数……という状態なので、狭いながらも、いろいろと事象が起きる。最近は、LinuxでもWineを使って、QXエディタ6.91+utf8マクロを動かし、テキスト編集をすることを覚えた。我が家の旧式PCは32bitマシンもおり、VSCodeが動かないから、もっぱらQXが頼りである。
もちろん、WineもOSもさまざまなバージョンと組合せがあるせいか、細かい癖の違いも本当に多い。(描画の乱れ方も千差万別、マクロ実行後にエディタ本体にフォーカスが戻らない程度はザラ、マシン・OS・Wineバージョンの組み合わせで、現れ方は本当にさまざま。)
だが幸い、編集が不可能になるほどの問題は起きていないので、WineでQXを動かし続けている。
Linuxで使えるということは、もし今後Windows11以降に見切りをつけて買うのをやめたとしても、一生、使い続けられるということである。悪い話ではないと思っている。Paper Plain xUiや、NyanFi、Bzエディタなどなど、手放せないWinアプリも多いが、みな、最近はLinux上で使っている。OpenMPTというアプリなどは、動作環境として、Wineを挙げてくれており、アイコンやメニューが登録され、Linuxネイティブアプリと区別がつかない。動作にも何の遅延もなく、トラック表示をスクロールで流しながら、MODをビシビシいい音で再生してくれる。こういう頼もしいアプリが増えると、ますますWindowsは要らなくなるので嬉しいが……この話は長くなるから、また別の機会にする。
さて、QXだが、たまに久々に仕方なくWindowsを立ち上げたときにだけ、テキストファイルのセーブができないことが多いのに気づいた。正確に言うと、
・サーバへのファイル新規作成は問題ない
・上記ファイルを変更して上書き保存しようとすると、QXエディタが「保存できません」と拒否する。他にも、自動バックアップがミスって「保存できませんでした」と哀しげなダイアログを割りこませてくる
・Linuxサーバ側のパーミッション等は関係がないみたいだ。悲しいことに、旧QXエディタだけが駄目で、NewQX、VSCode、サクラエディタ、すべて問題がなかった。もちろん、Windowsのメモ帳や、各Linuxディストロが備えるネイティブの各種テキストエディタで、問題が起きたことはない
・Windowsクライアントだけだと最初思っていたが、いつからか、Linuxクライアント(つまりWineで動く旧QX)でも起きるようになってきた
# 念のためサーバのSambaバージョンを確認
$ smbd -V
$ Version 4.15.13-Ubuntu
それでもおれは、使いなれた、カスタマイズし過ぎて何が何だか再現不可能になってしまっている旧QXエディタで編集を続けたいのだ。
ちなみに「セーブができない」ではなく、「セーブができないことが多い」と書いた。これは、おれの特殊な使い方が原因らしい。該当のLinux共有をネットワークドライブとしてマウントしてQXエディタでアクセスするとこの問題が起きるのだが、おれはさらに、substで短縮した名前にして使うことが多いのである。そしてなぜか、substしたドライブからアクセスすると、同じファイルでも、問題が起きず、QXくんはスムーズに上書きセーブを済ませてくれるのである。
イメージが湧かないと思うので実例を挙げる。
(1) D:\Text\Game\hogehoge\wao\gao\pap\a.txt
(2) E:\a.txt
(1)D:は、\\pm-express5800\homeをマウントした、ネットワークドライブだと思ってほしい。そのままだと長く深くて面倒なので、よく使うフォルダは、
subst E: D:\Text\Game\hogehoge\wao\gao\pap\
(2)のように、割り当てたEドライブ直下のファイルとして一発指定できるようにしているわけである。
2024年のいまどき、こんな古臭いやり方はかなり少数派、絶滅危惧種と思う。「おれの特殊な使い方」と書いたのは、このことである。
さて、古い・新しいはさておき、(1)でアクセスすると上書きセーブが拒否されるのだが、(2)だとうまくいくので、長らく気づかなかったわけである。
……ここまで読んだ読者は、「ははぁ、ファイル名の長さだな」と思われることだろう。おれも最初そう思ったんだが、どうもそう単純ではないようなのだ。もし、フォルダを含めたファイル名の長さが問題なのだったら、
E:\a.txt
が問題なかった以上、
D:\a.txt
も、問題ないに違いない、と思うでしょう。
でも、そこまで単純ではないようなのだ。切り分けのために、いっそ、D:というネットワークドライブを丸ごとsubstしたら、実はうまくいくのでは？と思ったんだが、そうでもないらしい。
subst F: D:\
とやっておいて、本当の名前は
D:\Text\Game\hogehoge\wao\gao\pap\a.txt
というファイルを、割り振ったFというドライブを指定して、
F:\Text\Game\hogehoge\wao\gao\pap\a.txt
にアクセすれば問題ないのかな、と思って試したが……しっかり上書き拒否された。何が違うんだろう？
しかも、しつこいけど、こんなことで悩ませてくれるのは、旧QXだけなのだ。
と言っても、もしかするとutf-8マクロを含めたなにかのせいかも知れないし、QX自体の問題とは断定できない。
で、いまどうしているかなのだが……とにかく駄目なのは旧QXの上書きセーブであるから、毎回名前を変えて保存する……のはヤメて、セーブだけ別のアプリに任せることにした。具体的には、WinMergeも、問題なくWineで動作するので、QXマクロ一発でWinMergeを呼び出し、比較してから、WinMergeにてファイル更新をすることにした。Wine上で動くWindowsアプリは、相互に呼び出しができるので、これは簡単に作れた。
・現在の編集中内容をテンポラリに保存
・上記テンポラリと、編集前の対象ファイルを、Winmergeで比較
最初こそ「なぜここまでしてQXを使うのか」と、自分で自分にため息をついていたが……こういう細工がパッと出来るのが、永年付き合ってきたアプリの良いところであり、結局離れられない理由でもあるのだ。それにやってみると結構快適な連携動作であり、かつ、いきなりテキストを上書きセーブせず、しっかり差分確認してからセーブするのは、良い習慣でもあり、推敲にも資することに気付いてしまった。キー一発でWinMergeがパっと起動して、編集したことすら忘れかけていた箇所を色づきで表示してくれるのは、実に実に快適な物書き環境である。というわけで、むしろ以前よりQXエディタを使うのがさらに楽しくなってしまい、Linuxでも、viはロクに覚えず、QXを使う日々なのである。