一括表示

常用環境での実験です。
#4802で、あとから挿入するファイル、すなわち.cgファイルを桁折した場合、１桁で桁折しても挿入異常が発生すると報告しました。ただ、先に開いていたほうのファイル、つまり.cgiファイルを桁折したときの実験は行っていませんでした。
そこで、0007.cgiファイルを削って１５行目（行頭が2632で始まっている行）までにしたファイルを作って、これを0011.cgiとしました。29685バイトのファイルです。このファイルのファイル先頭にそのまま0007.cgを挿入しようとすると、普通に、というか、今までと同じ異常挿入となります。まぁそうですよね、もっと小さいファイルでも異常挿入なんですから。

さて、この0011.cgiファイルを76桁で桁折して0011_76.cgiというファイルを作りました。さすがにこの桁数なら大丈夫だろう、と思って0007.cgを挿入したら、なんとびっくり、異常挿入発生。
先に開いていたファイルの桁数だけが原因、というわけではないらしい。
さらに、です。
念のため、もともとの0007.cgiファイルを76桁で桁折した0007_76.cgiというファイルを作り、こいつのファイル先頭に0007.cgを挿入したところ、正常挿入。なんだそりゃ。

ここで、あとから挿入するほうのファイル、すなわち0007.cgのほうも76桁で桁折した0007_76.cgというファイルを作成。そして、0007_76.cgiの先頭に挿入。うん、正常挿入。つづけて、0011_76.cgiの先頭に0007_76.cgを挿入したところ、これがなんと異常挿入。えぇ〜！
76桁で桁折したファイルの先頭に76桁で桁折したファイルを挿入して、なぜ異常挿入が発生するのだ。というか、これで異常挿入が発生するのなら、今まで報告がないことがおかしい。もちろん、変な文字コードとか改行コードがまぎれていれば起きるのかもしれないけど、ファイルの中身に関して、少なくとも数人の方に検証してもらっているはずなので、この線は消えるはず。

常用環境の何かがおかしいのかと思い、WinXPのcommand.comでVz1.60製品版の.comと.def、ただしBlだけ8192にの環境でも試してみましたが、

　0011_76.cgi に 0007.cg を挿入すると　異常挿入
　0007_76.cgi に 0007.cg を挿入すると　正常挿入
　0007_76.cgi に 0007_76.cg を挿入すると　正常挿入
　0011_76.cgi に 0007_76.cg を挿入すると　異常挿入

と、常用環境と全く同じ結果となりました。

いちおう、Vzのスクロールとtypeコマンドのスクロールを使ってファイルを流してみて、一見したところでは、76桁で桁折したファイルは３つとも、見た目には異常がないことを確認しています。

おかしい、何かがおかしい。
でも、何がおかしいかが全く分からない。
だけど、ここから先、追及の取っ掛かりも全くない。
そろそろおしまいかなぁ。

一夜明けて。

> 常用環境での実験です。

> 　0011_76.cgi に 0007.cg を挿入すると　異常挿入
> 　0007_76.cgi に 0007.cg を挿入すると　正常挿入
> 　0007_76.cgi に 0007_76.cg を挿入すると　正常挿入
> 　0011_76.cgi に 0007_76.cg を挿入すると　異常挿入

常用環境での結果が変わりました。

　0011_76.cgi に 0007.cg を挿入すると　異常挿入
　0007_76.cgi に 0007.cg を挿入すると　異常挿入
　0007_76.cgi に 0007_76.cg を挿入すると　正常挿入
　0011_76.cgi に 0007_76.cg を挿入すると　正常挿入

だけど、Vz1.60製品版での結果は昨夜と変わらず。
なんだろう、この挙動の不安定さは。
安定して異常動作なら追及のしようもあるのだけど。

　不穏当な比喩（連想）なのだろうと思いますが、日中国交正常化と尖閣諸島のことを思い出しました。
　�ｹ小平の言葉です。

「われわれの世代の人間は知恵が足りない。われわれのこの話し合いはまとまらないが、次の世代はわれわれよりもっと知恵があろう。その時はみんなが受け入れられるいい解決方法を見いだせるだろう」

　とりあえず、棚上げは良い考えだと思います。
　いつか、としきさんの努力が実って、解決する日がくると信じています。

棚上げの前に，誰か，ファイル挿入後に挿入開始位置から元ファイルと比較するマクロを書いてくれれば，今の茫漠とした不安が多少解消される方向に進みますよね。

> 一夜明けて。

さらにその後。
なんと、一番最初の結果に戻ってしまいました。すなわち

> > 　0011_76.cgi に 0007.cg を挿入すると　異常挿入
> > 　0007_76.cgi に 0007.cg を挿入すると　正常挿入
> > 　0007_76.cgi に 0007_76.cg を挿入すると　正常挿入
> > 　0011_76.cgi に 0007_76.cg を挿入すると　異常挿入

となりました。
これはVTDOS1.22とWinXPのcommand.comで同一です。

実はですねぇ。
内緒にしていたことなんですが、一番最初の実験のとき、アルコールが入っていたんですよ。そのせいで、最初の実験は何かをとちっていたのかと思っていたのですがね。どうやらそうではないらしい。また、追試の際は真昼間なんで、さすがにアルコールは入っていません。それに、何かがおかしいということで、特に挙動が変わった部分、command.comとVTDOSで何回も実験を繰り返していましたから、それなりに結果には自信がある。ということは、やはり挙動が不安定なのか。

一応、今回の結果について、また画面キャプチャを取りましたので、牧場の生簀？に放流してあります。
あ、そうだ、海豹牧場。
データのタイトルのところ、strongタグの閉じタグの後ろに、なんか妙な２バイトコードが混入しているっぽい。そう見えているのはうちの環境だけかな？

> 妙な２バイトコードが混入しているっぽい。

実は以前から気にはしているのですが，CGIのスクリプトでは全角スペースと'-'と全角スペースを出力するようになっているのです。
print "<dt id=\"N$no\">[$no] <strong>$sub</strong>　-　";

しかし出力されているのが D6h FFh D7h FDh の4バイトなんです。
出力しようとしているのは 81h 40h 2Dh 81h 40h なので全然ちがう。(^^;
謎。

> しかし出力されているのが D6h FFh D7h FDh の4バイトなんです。
> 出力しようとしているのは 81h 40h 2Dh 81h 40h なので全然ちがう。(^^;

ここ、うちでの認識とも食い違っている。
うちでは 81h 33h 38h 81h 40h の５バイトを受信しているように見える。
あ、これ、Firefoxでの結果。
一応、サーバのWinXPのIEからも確認してみましたが、同じ５バイトに見える。
何か変な文字コード変換が入っているのかな。

> print "<dt id=\"N$no\">[$no] <strong>$sub</strong>　-　";

あと、思いつくものとしては、その部分を一旦消して書き直したものを再アップロード、くらい？

33h と 38h は 38 で発言番号……　　あ (^o^;)

わたし，としきさんの「その2」のタイトルを見て，てっきり完全化けのダイヤ?の後ろの38は発言番号だと早とちりしてました。

ソースを表示・複写，バイナリで保存してダンプしたら， D6h FFh D7h FDh だったので，変な出力はそこだと思っちゃったのですよね。化けて見えているのはおそらく漢字の1バイト目で，直後に 33h 38h が出力されて，全角空白ひとつは一応正常に出力されたものなのかなぁ……(^^?

うーん，実験もめんどくさいや
「　-　」を削ったらもっとさらに一段とモノ凄いバケバケになったりして(笑)

まぁしかし，烏帽子親直々のご指摘だから，あたらおろそかにはできんか…。

半角スペースとコロンにしたら直りました。m(_'_)m

> 半角スペースとコロンにしたら直りました。m(_'_)m

これでまた、全角空白とマイナスに戻してアップロードしなおしても正常になってしまった、というパターンもありがちです。一方で、やはり文字化け再現なら、それはそれでデバッグのしがいもありそうですが。

そうだ、デバッグ。
デバッグといえば、異常が起きた祭に内部で使っている変数などを表示させる手法が一般的。ということで、この手法を例のファイル挿入マクロに適用するとしたらどういうことになりますでしょうか。
#i や #B の前後に &m を入れるのか、それともその前後では変数の保存だけしておいて、マクロ終了時にまとめて表示させるほうが良いか。
そもそも、どんな内部変数を追いかけるべきなのか。
内部変数の保存先は、汎用変数がいくらでも使えますから、その点の心配は不要だと思いますけど。
konnoさんがいろいろとソースに手を加えて、もうすぐ直りそうだというときにこんなことを聞くのはいかにもタイミングがずれているようにも思われますが、一応、基本に立ち返って、というか。もしかしたら、konnoさんの修正がきちんと機能していることの確認にも使えるかもしれない。

ということで、ぜひめざらさんのお知恵をお貸しいただければ。

> アップロードしなおしても正常になってしまった、というパターンもありがち

戻してみたら，結局文字化けだったので，半角スペース，ハイフン，全角スペースにしてみたら化けませんでした。ここの出力はわりと単純に文字列を出力しているだけなので，なぜ '>' の直後の全角スペースが化けるのか意味不明。'-' の直後の全角スペースは化けないのに……。

ま，それはそれとして，題。

> 異常が起きた際に内部で使っている変数などを表示させる手法が一般的

あのマクロの場合は，動作に影響のある保存変数を使っているわけではないので，&s を &t に変更してトレースしながら動作を追うしかないように思います。実際，今回の #B の動作におけるポインタずれを確認できたのは，非サイレントでのトレースでした。

トレースは「一般的」とは言えないですよね。そういう便利なデバッグ手法が使えるのは，いくらインタープリタでもそれほどあるとは思えない。トレース機能がなかったら，VZ を使い続けていたかどうか分からないですし，トレース時に戻り値と内部レジスタ値を表示するように改善した高橋版の偉大性は古今東西（大げさな）並ぶものがないと思われます。（井蛙談）

ポインタずれのことを考えると，テキストレコードにあるポインタ関連のダブルワード値を確認するのが手始めでしょうか。でも，これはすべてのケースではないですよね。としきさんが最初に確認した論理行の入れ替わりに関してだけで，文字化けを含むぐちゃぐちゃ系はテンポラリファイルの問題のような気がしますし…。テンポラリファイルはメモリの使い方に関わるので，マクロから確認することは困難なのではないかと思います。

> あのマクロの場合は，動作に影響のある保存変数を使っているわけではない

マクロそのものを考えると、おっしゃるとおりです。
私が考えたのは、なんというのかな、実は正確な用語がわからないのですが、Vzの内部の構造体とか何とか、ポインタで表すような部分とか、あるいは変数cpとか何とか、いくばくなりとも今回の異常動作に関係のありそうな周辺の変数のことです。
なぜこんなことを思いついたかというと、konnoさんがいろいろと検討するに当たり、内部情報を変数vnに保存して表に出す、ということをやられていたからです。
これと同じような手法で、内部の情報を表に引っ張ってくれば、正常動作と異常動作で何かが違う部分が見つけられるのではないか、と考えたわけです。
ただ、これも、おっしゃるとおり、あくまでも異常挿入のときの追跡に使えるだけ。
テンポラリファイル関係では、難しいものがあると思います。

> トレースは「一般的」とは言えないですよね。

大昔は逆に、とても一般的でした。
かつて、パソコンが８ビットの時代のBASICインタプリタでは、非常に多くの機種でトレース機能がありました。もちろん、トレース機能のONとOFFが可能で、デフォルトでは当然、OFFです。
さて、これがどのくらい一般的だったかというと、トレースをONにするBASICコマンドは「TRON」ですが、このコマンド名をタイトルとするハリウッド映画が作られたくらい。そして、当時のいわゆるパソコン少年たちは、この映画のタイトルの意味するところはすぐにわかったわけです。
何年か前、この映画のリメイクが作られたくらいですから、映画の内容はそれなりによかったのだと思いますが、でも、最近の人たちは、このタイトルの意味なんかわかっていないんだろうなぁ。
そして、コンパイラ言語ではトレースってあまり一般的ではないかもしれません。
でも、いわゆる統合開発環境というヤツでは、ブレークポインタなどを使うことで、擬似的にトレースできるようになっています。DOSのころのTurbo-CとかQuick Cとかにも搭載されていたのではないかなぁ。もう覚えていない。
また、例えば最近のExcelマクロとかの開発環境でもトレース機能はありますので、おそらく、めざらさんの思っているよりはありふれているのではないかと思います。
ただ、文太さんが好きそうなmakeコマンドでコンパイルするような環境だと、トレース機能なんてほとんどないと思います。知らんけど。

> ポインタずれのことを考えると，テキストレコードにあるポインタ関連のダブルワード値を確認するのが手始めでしょうか。

よろしければ、これの方法をお教えいただけないでしょうか。

ひとつコメントし忘れていたようです。

■テキストレコードにあるポインタ関連のダブルワード値を確認する方法

まず，以下のページを見てください。
・VZ構造体関連覚書　：　テキスト構造体（テキストレコード）
http://mezala.la.coocan.jp/vz/notes/struct.html#text_struct

カレントのテキストであれば変数 wa の値が先頭を示す構造体があり，要素ごとに先頭からの相対アドレスが示してあります。

そのうち，以下のダブルワード値を持つグループがあります。
+110　dword　tblkp　block lptr ブロックマーク位置
+114　dword　tnowp　current lptr
+118　dword　trgtp　target lptr
+122　dword　toldp　old current lptr

これらに格納された値は，マーク（0~4）のアドレスを扱うのと同様の方法で扱えるものです。実際の意味はソースを読める人に確認していただいた方がよいかとは思うのですが，wa+110（wa..55 + wa..56）が ^B 等でブロック指定を開始した位置で間違いないでしょう。wa+114（wa..57 + wa..58）はカーソル位置ですね。三番目と四番目はよくわかりません。何かのために保存されているのでしょう。

これらをトレース中に表示させるコードを仕込んでおきます。

&t &m("tblkp: [%lxh] / tnowp: [%lxh] ",wa..55,wa..56,wa..57,wa..58)

こんな感じでしょうか。

ブロックをペーストしたのち，Ek+ ならカーソル位置がブロックの最後に更新され，Ek- の場合は #B でカーソル位置が更新されますが，これらの動作の前後に表示されるアドレスが正常か異常（ポインタがずれる）かを確認することで，なんらかの解決への道筋が見えるかもしれません。見えないかもしれません。

> これで異常挿入が発生するのなら、今まで報告がないことがおかしい。

そうなんですよね。
ふつう（一行の長さが適度な…という意味）のファイルでは異常が出たという記憶がないところに，例の提供ファイルで不思議な現象が見られて驚愕……という流れだったわけで，ここでふつうのファイルでも異常が見られたということになると，何が何やら。

やはり多重の原因が想定されるのでしょうかね。

もともと、やれることはあらかたやったよなぁ、そろそろまとめにしてお開きにしたいよなぁ、ということだったんですよ。そこで、容易にできて、かつ、漏らしていることは何かあったかな、ということを考えて、そうだ、先に開いているほうのファイルの桁折は試していなかったな、というところで試してみたところ、びっくり。

> ふつう（一行の長さが適度な…という意味）のファイルでは異常が出たという記憶がない

マクロをバリバリ使うような方々の場合、以前にめざらさんの提示されたような各種のマクロを使うので異常が出ない、ということはあるでしょう。でも、かつて、DCでもマクロに関してはライトなユーザーが何人も出入りされていて、そしてそれらの方々からもファイル挿入で異常があったという話は全く出ていない。ということは、純正マクロで異常が出ることはほとんどなかった、と推測することが可能。

#4680で示したとおり、もともとの桁折していない0007.cgiと0007.cgの場合、PC-98で異常挿入になりました。ここから、原因が環境に依存している可能性は低く、挿入する、または挿入されるファイルに原因がある可能性が高い、と思っていました。そして、これらのファイルを見た場合、真っ先に目に付く特異性が、著しく長い論理長が含まれる、ということ。そこで、この線を追いかけて、

・あとから挿入されるファイルを1桁で桁折しても異常挿入になる
・先に開いているファイルを削っていって、あるスレッショルドよりも小さいファイルサイズにすれば異常挿入は解消される。
・上記スレッショルドの値はBlによって変化する

というところまでは追い込めました。
また、このスレッショルド値は、どうやらkonnoさんのところでもおなじようなので、何らかの環境が一致すれば常に一定になることが想定されました。
一方で、めざらさんの環境ではテンポラリファイルエラーが多発。
また、文太さんのところでは、環境ごと落ちまくっていましたよね。
つまり、テンポラリファイル関係でメモリリークが起こっているような気もする。そして、Vzの動いている環境によっては、つまり、VTDOSだとかWindowsのcommand.comのバージョンとかによっては、システムを道連れにしているのではないか、と思っていたのですよ。
今回の事象にめぐり合うまでは。

> やはり多重の原因が想定されるのでしょうかね。

結局はそういうことなんでしょうね。
あぁ、もうそろそろ終わりかと思ったのに。
また試してみたいことが増えてしまった。

とりあえず、今後の方針。
あまり関係はないと思いますが、いくつか潰しておきたいことがあって。
WinXPの実験環境ですが、command.comは普通に25行なんですが、VTDOS1.22の常用環境は50行なんです。そこで、VTDOSのほうでも25行にした場合、挿入異常の状況が変わるか否か。もし変わるとなると、画面表示に関するバッファによっても挙動が変わるということで、これは手がかりの一つかもしれない。今のところ、私としては、変わらないと思っているのですがね。でも、そもそも、76桁で桁折したファイル同士で異常挿入が起こるとは思っていなかったわけで、もう何が起こっても驚かないという覚悟が必要だったりするかも。
もうひとつは、実家のPC-98で76桁で桁折したファイル同士で挿入を試してみる、ということ。こちらも、異常挿入は起きないことを期待しているのですが、はたしてどうなることやら。

ここに付けておこう。

> そこで、容易にできて、かつ、漏らしていることは何かあったかな

以前、文字コードが云々、という話を出したことがあったと思います。
改行コードはともかく、文字コードだけなら簡単にチェックできる方法を思いつきました。問題のない文字を削除してしまえばいいのです。
ということで、半角のアルファベットと記号、空白、および全角の英数字、ひらがな、カタカナ、記号、第１水準漢字を削除してみました。結果、残るのは半角数字と第２水準漢字のみ。0007.cgiと0007.cgともに、ざっとスクロールさせて見ましたが、特に問題のありそうな文字は残っていませんでした。
ついで、半角のアルファベットと記号を１文字ずつ半角の空白に置換。さらに、全角の英数字、ひらがな、カタカナ、記号、第１水準漢字と第２水準漢字をそれぞれ半角の空白２文字に置換。こうすることで、ファイルサイズ、行数、および各行のバイト数を保ったままで、２バイト文字のないファイルが完成します。この２バイト文字のない、0007null.cgi（仮）を開いた状態で、ファイル先頭に0007.cg（仮）を挿入したところ、やっぱり異常挿入。すなわち、行頭が2515で始まる行の１つ上の行が2795で始まる行になってほしいところが、残念ながら2599で始まる行となってしまっていました。
ここからわかることは、２バイト文字の有無が今回の異常の原因ではない、ということ。何を疑っていたかというと、何か（テンポラリファイル？）の処理において、２バイト文字の真ん中で分割しようとしたときにこけているのかも、と思っていたのですが、その疑いは晴れました。

うぅぅ、思いつきで容疑者を取り調べても、全部シロ。
ここはやはり、証拠を一つ一つ丹念に追いかける必要がありそう。

としきさん

> ここからわかることは、２バイト文字の有無が今回の異常の原因ではない、ということ。何を疑っていたかというと、何か（テンポラリファイル？）の処理において、２バイト文字の真ん中で分割しようとしたときにこけているのかも、と思っていたのですが、その疑いは晴れました。

これは私も疑っていたので、1.57のルーチンを見て弄ったりしていました。
疑いが晴れたので、元に戻したらいい感じになってきました。
ありがたいです。

不思議な挙動については、私はファイルサイズが関係していると思っています。
$8000、32768 に近いところに異常の境界があるように見えるので。
Bl との関係は、Bl の後ろにある tmpbuf4 などのバッファが関係している気がします。

> うぅぅ、思いつきで容疑者を取り調べても、全部シロ。

思いつきで一つ実験してみたら、ちょっとびっくりしたことがあります。

konnoさんのところで、LFを検索して改造するところの見当をつけた、という話がありました。そこでふと、改行コードを全てCRLFからLFのみにしてみたらどうだろう、と思いました。
使ったツールはnkf。
0007.cgiと0007.cgを、CRLFからCRのみとLFのみに変換したファイルを作ってみました。
結果、ファイルサイズは同じ、かつファイルサイズの減少量は行数と同じなので、もともとのファイルの改行コードは全てCRLFでした、ということが確認できました。
で、当たり前かもしれませんが、CRだけのファイルだと、確実にテンポラリファイルエラー。まぁそうですよね、Vz的には先頭から末尾までがたった一つの論理行扱いですから、こんな長い論理行のファイルが正常に扱えるわけがない。
ところが、です。
.cgiをLFのみにしたファイルを開いておいて挿入しようとすると、CRLFのファイルもLFのみのファイルも正常挿入。
一方、CRLFのファイルを開いておいた場合、LFのみのファイルを挿入しても異常挿入。

なんとなくですが、konnoさんのアプローチは正しいと思う。
ただ、LFのみのファイルにしても、めざらさんのところで発生しているテンポラリファイルエラー事象は改善しないような気がする。
もしヒマがあれば追試してもらえるとうれしい　＞　各位

すっかり忘れていました。
気がついた人は気がついているかもしれません。

> WinXPの実験環境ですが、command.comは普通に25行なんですが、VTDOS1.22の常用環境は50行なんです。そこで、VTDOSのほうでも25行にした場合、挿入異常の状況が変わるか否か。

#5106で触れている、海豹牧場にアップした画面キャプチャ。
command.comとVTDOSの両方、25行での実行結果です。
つまり、両方とも同じ行数で同じ結果となりました。

一応、報告というか再確認、でした。

> やれることはあらかたやったよなぁ、そろそろまとめにしてお開きにしたいよなぁ、

と、元発言にも書きました。
今年は１年、ほとんどこの問題に費やしてしまいましたが、今度こそ何とかお開きにしたい。できれば今年中、それが無理だとしても、問題提起１周年の来年２月までには。

とりあえず、この辺の発言に関係の深いところをひとつ。
WinXPの常用環境です。
76桁で桁折しておいた0007_76.cgiを開いておき、0007_76.cgを挿入しました。
このときまでは、いろいろなものを動かしていたので、環境的には汚れていたかと思います。結果、異常挿入。また、ここでcmd窓からcommand.comを起動したのですが、そこでも異常挿入。
その後、マシンそのものを再起動。そしてVTDOSを起動して同じことを試したら、今度はなんと正常挿入。command.comでも正常挿入。これだけの結果を見るとなんとなく、ＯＳの側の環境が汚れた結果がVTDOSとcommand.comの両方に影響を与えたように見えます。
なんとなく釈然としないまま、再度マシンを再起動。それからVTDOSを起動して試してみたら、再び異常挿入。え、なにそれ。さらにcommand.comでも異常挿入再現。おいおい。

こんなに状況が不安定では、追跡をあきらめるのが妥当なような気がしています。


もうひとつ。
WinXPのcommand.com、製品版1.60で。
いろんなバッファを削りまくってみました。
具体的にはこんな感じ。

* O オプション

Bt64 ;テキストバッファのサイズ (16..64KB)
;Bq0 ←1.6無効
Bf1 ;DOSコマンド用メモリの最小値 (KB)
Bo1 ;コンソール出力取込みバッファサイズ (0..32KB)
;GV0 ←1.6無効
EM ;ＥＭＳの使用ページ数 (EM1:残り全部)
XM0 ;ＸＭＳの使用サイズ(KB,XM1:残り全部) ##1.6
SW3 ;スワップモード
;(0=OFF, 1=text, 2=text&code, 3=TSR 3.8KB)
RM0 ;ＥＭＳ／ＸＭＳの解放の禁止(+1:EMS, +2:XMS) ##1.6

Bm1024 ;マクロバッファのフリーエリア
Ba0 ;エイリアスバッファ 〃
Hs4 ;文字列ヒストリー 〃
Hf4 ;ファイル名 〃
Hx4 ;DOSコマンドライン 〃
Bl8192 ;行バッファサイズ (256..(Bt*1024/8))
Bc16 ;削除文字列バッファサイズ
Bu4 ;マクロ配列領域サイズ
Bv4 ;ログファイル履歴バッファサイズ ##1.6

TC4 ;オープン可能なテキスト数


このときのcsegmapは

Cseg map : 2022/12/24_23:17:41
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 @@@@@@@@@@@@@@@XXXXXXXXXXXXXXXXi
1 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
2 iiiiiiiooooooooXXUUUSSSSSSSSS---
3 ----@@@-------------------------
4 ---------------:::::::--========
5 ================================
6 ========================--------
7 --------------------------------
8 --------------------------------
9 --------------------------------
A --------------------------------
B --------------------------------
C --------------------------------
D --------------------------------
E --------------------------------
F --------------------------------
0 1 2 3 4 5 6 7 8 9 A B C D E F

となりました。
この状況で0007.cgiを開いておいて0007.cgを挿入して異常挿入。
これより、バッファの使用量が限界を突破したことで異常が発生、という可能性はほぼないのではないか、という気がしています。つまり、関係ありそうなオプション指定はBlとBtだけ、ということ。ここからもしかすると、何かが判るような気もしますが、少なくとも私には、追及は無理そうです。

> その後、マシンそのものを再起動。そしてVTDOSを起動して同じことを試したら、今度はなんと正常挿入。command.comでも正常挿入。これだけの結果を見るとなんとなく、ＯＳの側の環境が汚れた結果がVTDOSとcommand.comの両方に影響を与えたように見えます。
> なんとなく釈然としないまま、再度マシンを再起動。それからVTDOSを起動して試してみたら、再び異常挿入。え、なにそれ。さらにcommand.comでも異常挿入再現。おいおい。
>
> こんなに状況が不安定では、追跡をあきらめるのが妥当なような気がしています。

これ、私も似たような状況に何度も会いました。
BL1024*3 の対策で、一度は正常になったと思ったのが、次は異常になったりして。
PCやOSの環境が関係しているのでしょうかねぇ。

> Bl8192 ;行バッファサイズ (256..(Bt*1024/8))

これを見て、BL256 から使えるんだっけと思って試してみたら正常でした。
BL1024*9 〜 BL1024*15 までも正常でした。

BL1024*3 近辺はラップアラウンドエラー
BL1024*8 近辺はCPズレで異常になる？

この2点は特異点ということでしょうかね。
原因は恐らく条件分岐のミスではないかと。
やはり2か所はバグがあるように思えます。
ああ、自分の無能さがはがゆい。

としきさん

>これで異常挿入が発生するのなら、今まで報告がないことがおかしい。
　とも言えないのかな、と思っています。
　全国に何人のユーザがいたんだろう？　３０万人、４０万人？　でもこのマクロを使って深刻にトラぶった人は、もうマクロかＶｚかをすぐ捨てたと思う。ほんとにバグが出たらですけどね。
　nifty界隈の人たち、『マコレ』みたいな上村本を買うような熱心なマクロユーザは、たぶん、上村さんのマクロを使っていたでしょう。
　もっとマニアックな人は、標準マクロを書き換えていたでしょう。
　だから、過去ログにないことは（報告がないことは）別に珍しいことじゃないと思う。
　まだまだ未発見のバグがあるだろうということ。

　さて、調査報告。vz 156には、同じマクロがそのまま含まれていた。古いマクロです。
　AP, PK, DC のログを「ファイル挿入」でグレップしたところ、色々興味深いものはでてきたけど（和生さんとか）、としきさんに喜んでもらえる「報告」と呼べるものはなかった。

　最後。仕様かもしれなし、僕はバグと呼ぶものの新種発見。

-----

あ

い


-----
　空行４行に全角スペースを入れたい。

srch string:
\x ^$

repl string:
　
;上は全角スペース

　バグですよね。\nを使った置換ては完全には処理できないと思う。現実の対象は５００行とかです。
　ただ驚いたのは、これをやった人がＤＣにいなかっただろうということ。
　FGALTSの人たちがばんばんＶｚを使っていたら（マニアックに使っていたら）、ま、仕様という結論になるかもしれないけど、密かに「おい、vwxってバグバグだぜ」とひそひそ話をしただろうな、ということ。

　一番大事な教訓は、VzerはVzのことしか知らないし、Vzにしか興味がなかった、ということです。
　僕の学んだ教訓です。
　ちなみに、上の置換処理は、filter.def + sed.exe でこなしました。
　ほんとうに一番驚いたのは、僕が「\x ^$」をＶｚで使ったことがなかったことでした。わお。


>Ygrep -%% " ^$" c:\tk\vzlog\dc ;not RegEx
　とやったら使っている人はいました。全角が問題なのかなぁ。
　バグだ、バグだとは、たぶん誰も言ってなかったと思います。
　僕は、探求することなく、「\x ^$」はＶｚでは使いません。
　地雷をひとつ報告しました。

結論としての「教訓」には，ちょっと同意しかねますね。
「まだまだ未発見のバグがあるだろうということ。」には同意します。
（プログラムにバグは付き物だから…と言うか，バグのないものはない。）

使用するソフトウェアの長所と短所の天秤であろうと思います。
昔と違ってマルチタスク環境が普通だから，補えばよいことですし。
（esegrep.defなんて作ってる人間の言うことは説得力がないでしょうが。）:-)

置換と検索は違う (c) 高橋　洋光

> >これで異常挿入が発生するのなら、今まで報告がないことがおかしい。
> 　とも言えないのかな、と思っています。

ん〜、まぁそうかもしれない。
でも、

> 　でもこのマクロを使って深刻にトラぶった人は、もうマクロかＶｚかをすぐ捨てたと思う。

こっちのほうはどうなんだろう。
なんか変、と気が付いて、誰にも頼れなければすぐに捨てるでしょう。
でも、ニフティやその他のネットにアクセスしている人たちで、そういうトラブルに出会った人が有意に少ないとはとても思えない。例えば、ニフティだけでも、FGALTSをはじめ、その他にも日本語関係のフォーラムとかも多数あったわけだし。

> 　まだまだ未発見のバグがあるだろうということ。

これには同意。
でも、頻繁に使われる機能が頻繁に使われる状況で不具合をきたす、というのは少ないと思う。そういうのはそれこそ、上村さんなり高橋さんなりEmmettさんなりが報告しているはず。
逆にいうと、ファイル挿入などというものは頻繁に使われる機能ではないのかも。

> 　最後。仕様かもしれなし、僕はバグと呼ぶものの新種発見。

確かにバグっぽい挙動ですね。
ただ、私、行末の検索にはvwx経由の正規表現の$を使うよりも\nを使ったほうがよい、という話をどこかで見かけた気がする。それこそ、空行ではない状況においても。
とはいえ、今回は空行を何とかしたい、という案件ですよね。
過去ログを空行で検索しても、空行処理の定番方法みたいなものは見つからなかった、ということなんですよね。

> 　「おい、vwxってバグバグだぜ」とひそひそ話

FGALAPとかFGALPKとかでやっていそうな気もしてきた。

> 　とやったら使っている人はいました。全角が問題なのかなぁ。

半角ならＯＫですか？

>> 　「おい、vwxってバグバグだぜ」とひそひそ話
>FGALAPとかFGALPKとかでやっていそうな気もしてきた。

　面白い！　
　で、APとPKの人たちが、DCの連中、それに気づいてないらしいよ、とさらにささやく。
　DCが終わっても、まだきづかなかったらしいよ、とAP/PK people.
　リトルピープルみたいな気がしてきた。

> >> 　「おい、vwxってバグバグだぜ」とひそひそ話
> >FGALAPとかFGALPKとかでやっていそうな気もしてきた。

あ、なんとなく私の意図が正しく伝わっていないような気がする。
もしかしたら私がニフティに入会する前の時代のことかもしれませんが、かつて、Vzの話題ってFGALAPやFGALPKで扱っていたと聞いたことがありまして。そして、DCができてVzの話題はDCに巻き取られた、という形だと思い込んでいます。この辺、めざらさんなら真偽というか時系列をご存知だと思います。
で、その時代、そのあたりのフォーラムではひそひそ話が行われていたけど、そういった情報がFGALDCには引き継がれなかった、ということを言いたかったのでした。

>あ、なんとなく私の意図が正しく伝わっていないような気がする。
　あう、ぜんぜん面白くない。
　さらに面白くない話をつづければ、vwxは、Vz 1.6からなので、DCからなんです。
　こそこそ、こそこそ、AP/PK ピープル。

> 　さらに面白くない話をつづければ、vwxは、Vz 1.6からなので、DCからなんです。

vwxが1.6から、というのは覚えていました。1.5も持っていましたからね。
ただ、時系列というかタイミングというか、DCが1.6から、というのは知りませんでした。
そうだったのか。ありがとうございます。

>ただ、私、行末の検索にはvwx経由の正規表現の$を使うよりも\nを使った
>ほうがよい、という話をどこかで見かけた気がする。

　ま、そうかなぁ、とも思う。ただ、当たり前ですけど、\nをキーにして何かしようとしても、もう正規表現の世界の外ですから、[A-Z] or [0-9]の文字クラスすら使えない。恐ろしく能力が低下します。

　で、正規表現導入前のＶｚ（1.6未満、wing版Ｖｚというのもあったけど）のことを考え、簡易的正規表現として、「\0」とか「\A」とかあったな、と思い、1.5 と 1.6 のマニュアルを見たけど、たぶん、両者に記述なし。
　遊びの「隠しコマンド」みたいな扱い？　『続天』ぐらいには書いてあったような気がするのだけど。

　とらじさん曰く「マニュアルのないソフトには慣れてます。Ｖｚで鍛えられましたから」。
　Ｖｚ解説本が１００種類近く出版されたわけだよなぁ、と。

>ファイル挿入などというものは頻繁に使われる機能ではないのかも。

　僕はそう思っています。catで連結はできるし。
　ファイルが壊れたときじゃない？　必要なの。ま、そういう時にはパニックしてますから、Ｖｚマクロで修復しようと考える余裕はない、とか。

　vwx のなんかのオプションのせいなのかなぁ。

------



------

　ああ、空行処理に、とにかく弱いのね。

　上の空行３行をブロックして、

srch string:
\x ^

repl string:
tab

　とやってみてください。
　３行目だけ効かない。
　４行ブロックすると、そんなことしたくないんだけど的に、４行目の破線行頭にもタブを入れてくれる。回避策はない模様。

　では、ハイフン行を含む５行をブロックして同じ処理をしてみてください。
（カーソルは下の下線の下にある）
　おお、できるじゃない！

\x ^
\x $
\x ^$

　なんかには、vwx はとにかく弱く、クセがありますね。

　だからぁ、疲れてるときに余計に疲れさせないでよぉ。
　寝まーす。

　こんなに気づいていないのが（vwxの常識として知られていないのが）あるとは、知りませんでした。
　僕がこれらに気づいたのは、僕がこのところ、プログラミングをしているからです。
　日常業務でこれらは使いません。ド文系は、そんな使い方をしないのです。

bug 1: #4938
bug 2: #5103
bug 3: ココ（たぶん、#5131）