一括表示

> 今のところ、この方向はこれ以上追及するつもりはありません。
> そもそもイレギュラーだったわけだし。

そのつもりだったのですが、一応、網羅的に、ということで。
試したファイルは0007.cgiと0007.cgが元のファイル。
それぞれに#4728のスクリプトをかけたのが0008.cgiと0008.cg。
#4736に書いた、0007.cgiの15行目だけを2分割したファイルが0009.cgi。
あと、0007fold.cgというのは#4746に書いたファイル。
そして、それらを使った結果が以下のとおり。


　　　　　　　　　　　あとから挿入するファイル
　　　　　　　　｜0007.cgi｜0008.cgi｜0009.cgi｜0007.cg ｜0008.cg ｜0007fold.cg
−＋−−−−−−＋−−−−＋−−−−＋−−−−＋−−−−＋−−−−＋−−−−−−
先｜0007.cgi　　｜試さず　｜試さず　｜試さず　｜異常挿入｜異常挿入｜正常挿入
に｜0008.cgi　　｜試さず　｜試さず　｜試さず　｜正常挿入｜正常挿入｜正常挿入
開｜0009.cgi　　｜試さず　｜試さず　｜試さず　｜正常挿入｜正常挿入｜正常挿入
い｜0007.cg 　　｜異常挿入｜異常挿入｜異常挿入｜試さず　｜試さず　｜試さず
て｜0008.cg 　　｜異常挿入｜異常挿入｜異常挿入｜試さず　｜試さず　｜試さず
い｜0007fold.cg ｜正常挿入｜正常挿入｜正常挿入｜試さず　｜試さず　｜試さず
た｜
フ｜
ァ｜
イ｜
ル｜


なかば予期していたことではありますが、0007.cgiに0007fold.cgを挿入した
場合が正常挿入ということからも、なかなか発現しづらい現象に遭遇して
しまったのだぁ、という思いを強くする今日この頃でした。

あと、特記事項というか、上記の結果はあくまでも、DOS窓を開いてすぐのとき
のみ、ということ。いろいろと作業ををしていて、ふと思い立ってファイルの
挿入を試すと、上記で正常となっているところも異常だったことがあります。
これはおそらく、コンソールファイルか何かわかりませんが、何かのファイルの
テンポラリファイルへの移動が関係するとかメモリ使用状況が違うとかがあった
ためだと思われます。
 

そんなとしき兄に，榊原さんの「一目で比較」．

========== HIKAKU.DEF ==========
* M
89 ^\ "一目で比較"
        ?.
        a=wn,b=wt,
:A      &k (r==$1b)?>Z          ;[ESC]で終了
;       &w(1)                   ;★必要に応じて入れて下さい
        #W &#Y(wt)              ;画面入れ替え
        >A
:Z      (b&1)?#W &#T(a)         ;画面復帰
*

あるいは，m.gann師のマクロ連続実行．
50 @W ""        ;Swap Text (18)         ;テキストの入れ替え
        ?. #W &#Y(wt)                   ;簡易テキスト比較にも使える

飛ばない論理行長

--- test.awk ---
{ print length($0) }
----------------

I:\WW>gawk -f test.awk 0008.cgi
1501
822
1513
3703	;max
4214	;erase
1794
1393
1824
1867
984
655
2501
723
2138
4023	;erase
1682

　0008.cgi対象の場合、「;erase」の２行を削れば飛びませんでした。
　3703 bytes の論理行は耐えるようなので、僕の 2560 bytes より、けっこう
長いみたいですね。もっとも他にも実は入っている要因とかもあるのかもですね。
　Bl8192, Bt64 の環境です。

　こんな長い行を扱うことになるとは……。
　そして日本語化はどうなってたっけ？　というわけで、Vectorとかで調べてＤＬして。
　こんな連中と（様さまと）、お付き合いいただこうか、という次第です。
　mawkは、いろいろとうまくいきません。

>２バイト文字が混在するファイルの場合、jgawkで算出しなければならないところ、
>gawkで計算していました。なので、これらの数値はバイト数ではなく文字数


C:\>jgawk -v	;もっとも伝統的な gawk for DOS
Japanized Gnu Awk (jgawk) 2.15.2 + 1.1(SJIS)
POSIX options:		GNU long options:
	-W version		--version
----------------------------------------------------------------------

C:\>gawk --version
GNU Awk 3.1.0
Copyright (C) 1989, 1991-2001 Free Software Foundation.
----------------------------------------------------------------------

C:\>gawkw --version	;gawk for win32, これをgawkと言いたいんだけど、色々あります
GNU Awk 3.1.5
Copyright (C) 1989, 1991-2005 Free Software Foundation.

本プログラムはフリー・ソフトウエアです。Free Software Foundation 公表の
----------------------------------------------------------------------

C:\>gawkm --version	;gawk with multi-byte
Gnu Awk (gawk) 2.15, patchlevel 6 + multi-byte extension 1.04
----------------------------------------------------------------------

C:\>mawk -W version
mawk 1.3.3MsDOS Nov 1996, Copyright (C) Michael D. Brennan
  Adaptation for MBCS (P. yedoensis R28) by KIMURA Koichi

Microsoft C/C++ _MSC_VER 803
compiled limits:
max NF             32767
sprintf buffer      1020
stack size         32380
----------------------------------------------------------------------

　やっと整理ができた。たんにコレクターなだけです。でも思うに、
これらの(m,g)awkとともに残りの人生を生きることになるのでしょう。
この方面でもう進歩も進化もないんだろうなぁ。
　『入門 JGAWK』みたいな本を買っておいて、よかった。どこにあるのか
知らないし、これから本当にこれらのお世話になる機会があるのかも
分からないけど。
　たぶん、VTDOS環境で、mawk32.exeは動かなかったと思います。
　以下、WinMEで、整理しました。

-----------------------------------------------------------

C:\BIN>mawk -W v
mawk 1.3.3MsDOS Nov 1996, Copyright (C) Michael D. Brennan
  Adaptation for MBCS (P. yedoensis R28) by KIMURA Koichi

Microsoft C/C++ _MSC_VER 803
compiled limits:
max NF             32767
sprintf buffer      1020
stack size         32388

-----------------------------------------------------------

C:\BIN>mawk32 -W v
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan
  Adaptation for MBCS (P. yedoensis R27) by KIMURA Koichi

Microsoft C/C++ _MSC_VER 1100
compiled limits:
max NF             32767
sprintf buffer      1020

-----------------------------------------------------------

C:\BIN>dir mawk*.*

MAWK     EXE       153,447  00-02-28  22:19 MAWK.EXE
MAWK32   EXE       193,536  98-08-22  22:02 MAWK32.EXE

-----------------------------------------------------------

　当然、異常発生はなし。

　ここに貼ってよいですか？　標準ｄｅｆではないです。僕の常用環境。

【Win7 Pro 32bit】

C:\>$ver
VTDOS Version 1.53 Build [Sep  5 2017]	;これは常用ではないけど。
　※イエイ！　落ちなかったぞ。

Vz version:
k07t01

vz.def  30,780  2020-08-11  14:19

Bl8192			;line buf (256..(Bt*1024/8))
Bt64			;テキストバッファのサイズ (16..64KB)
Bm20000			;

使用マクロ：
8  [ESC]I "Insfile" 	&88


001.txt冒頭に002.txtを挿入

2013/06/05  09:54      15,448  001.txt
2022/06/18  18:25      13,969  002.txt
						;↓　mlen = max length
2022/06/18  18:25       2,074  001mlen.txt	;001.txtの最長行（注）
2022/06/18  18:26       1,096  002mlen.txt	;002.txtの最長行

2022/06/18  18:27      29,417  kek.txt		;異常なし

1994/03/01  14:26       1,653  NAGASA.DEF	;by syoさん
1994/03/01  12:59       1,111  NAGASA.DOC	;最長行測定に使用。
						;さすが、syoさん！
						;かわいかったですよ、nagasa.def

（注）ふつうの本の１段落が１０００字程度ということ。１論理行が 2,074 bytes.
　　　終端の改行を含む。
-----------------------------------------------------------------

【WinME 32bit】

Windows Millennium [Version 4.90.3000]

2022-06-18  18:35      29,417 kek_me.txt	;異常なし


　考え方に関しては、#4718 のめざらさんの考え方が、そうでしょうね、
と納得できるものでした。でも、2000字（4KB）の論理行は、じゅうぶんあり得るな、
とも思う。変な作家はいますから。
　もちろん、ごめんなさい、話をぜんぶ追えられているわけではありません。

　不具合発生条件が満たされる状態でも、WinMEと純DOS (LX, moba, OA pocket)では
挙動はきっと同じでしょう。

　結果。異常は見られず。

【Win7】

>dir
2022/06/18  23:00           302,888 0007-i.cgi		;(1)
2022/06/18  23:00           132,553 0007.cg
2022/06/18  23:02           302,888 0007.cgi		;kek, (1) に同じ

C:\>diff c:\ww\0007.cgi c:\ww\0007-i.cgi

 Blank, these two files are identical.

-----------------------------------------------------------------------

【Win ME】

C:\>diff e:\ww\0007.cgi e:\ww\0007-i.cgi

 Blank, these two files are identical.

------------------------------------------------------
8 @I "I カーソル位置へ挿入"
	?. (mr==$80)?{ &m(36) . }
	&m("カーソル位置へファイルを読み込みます")
        <cut, below>
------------------------------------------------------

【Win7】

C:\WW>diff i:\ww\0007.cgi i:\ww\0007-i.cgi

 Blank.


【Win ME】

C:\>diff e:\ww\0007.cgi e:\ww\0007-i.cgi

 Blank.

　どうやら、僕のＶｚ環境は最強みたいです。でません。別にでてもらわなくて
構いませんが。

　別に「どうやったら出るんですか、オプション設定の何が足りないんでしょうか」
とも思ってません。
　すいませんね、こんなことになると思ってました。すいませんけど、あんまり先は
ないと思います。

としきさん

　「みなを巻き込んでしまった」とか思う必要はないと思います。
　そこそこ、不具合を楽しむ、いろんな復習をさせてもらってる、のだと
思いますから。
　ネタがないと、やっぱり困るし、つまんないし。
　たまには基礎から復習。ありがたや。


0007-i.cgi  302,888  2022-06-19  21:27	;あれ、何か変更を加えてしまったらしい
0007-i.out  303,361  2022-06-19  21:32	;nagasa.defの後、どんなファイルなの？
					;と見てやろうと
					;#56 "\n" "\n\n" とかしました。

C:\>vmap
----- EMS ver4.0 (frame: C000h) -----       ----- XMS ver2.00 -----
handle pages   size  name                   HMA used: 63 KB by DOS
------ ----- ------  --------               EMB free: 32415 KB
     1     2    32k  for Vwx!
     2     6    96k  VZ

　0007-i.out、オープン状態です。
　テンポラリーファイルがＥＭＳに行ってる。「ここで落ちるな、VTDOS」とか祈ってました。
　swap.asmとかも、ありましたね。

　僕はnagasa.defがまともに機能するとは最初思ってなかったんです。
　しっかり作りこんであった。さすがローテク。vz.comも、もちろん立派。

　で、＃５６とかしてるときにＶｚは落ちるは、ＶＴＤＯＳも落ちるはと、色々あった
模様です。意外に長い行がいっぱいのファイルだった。
　ラインバッファ、テキストバッファ、テンポラリーファイル。すげえな、このエディタ。

　意地にならなくてもいいんじゃないですか、と、怒られそうなことを思ってます。
　insfile.defにすればいいんだし。
　ま、やりたいんだから、やりたいだけやるの、もちろん、ありです。
　あ、あかん、insfile.def、ステキも、少し推奨。上村さんにも感謝です。
　『マコレ』とか、まだ捨ててません。

　swap.asmとか、最初からあったのか？　あれはすごいだろう（怖くて使わなく
なってますが）とか思ってしまいまして。好きなんですよ、なんだか、とっても。
お許しください。

>dir (v.1.01)				>dir (v.1.60)

1989/06/30  10:01   8,185 ALIAS.ASM	1993/12/06  02:00   8,643 ALIAS.ASM
1989/05/10  10:00   3,433 CHAR.ASM	1993/12/06  02:00   5,649 CHAR.ASM
1989/06/30  10:01  17,349 CORE.ASM	1993/12/06  02:00  19,033 CORE.ASM
1989/05/10  10:00  10,476 DISP.ASM	1993/12/06  02:00  13,392 DISP.ASM
1989/06/30  10:01  14,570 DOS.ASM	1993/12/06  02:00  19,459 DOS.ASM
1989/06/30  10:01  11,132 EXPR.ASM	1993/12/06  02:00  15,269 EXPR.ASM
1989/06/30  10:01  29,433 FILER.ASM	1993/12/06  02:00  56,965 FILER.ASM
					1993/12/06  02:00  15,591 EMS.ASM
1989/06/30  10:01   6,427 GETS.ASM	1993/12/06  02:00   8,134 GETS.ASM
1989/05/10  10:00   2,080 HARDERR.ASM	1993/12/06  02:00   2,120 HARDERR.ASM
1989/05/10  10:00  15,283 INST.ASM	1993/12/06  02:00  22,446 INST.ASM
1989/06/30  10:01  14,847 KEY.ASM	1993/12/06  02:00  14,044 KEY.ASM
1989/05/10  10:00  10,322 LEDIT.ASM	1993/12/06  02:00  12,050 LEDIT.ASM
1989/06/30  10:01  22,836 MACRO.ASM	1993/12/06  02:00  42,233 MACRO.ASM
1989/06/30  10:01  27,220 MAIN.ASM	1993/12/06  02:00  36,713 MAIN.ASM
1989/06/30  10:01  14,735 MEMO.ASM	1993/12/06  02:00  15,741 MEMO.ASM
1989/06/30  10:01  15,261 MENU.ASM	1993/12/06  02:00  19,360 MENU.ASM
1989/05/10  10:00   3,612 MISC.ASM	1993/12/06  02:00   4,023 MISC.ASM
					1993/12/06  02:00   6,685 MSG.ASM
1989/06/30  10:01  14,297 OPEN.ASM	1993/12/06  02:00  29,942 OPEN.ASM
1989/05/10  10:00   4,722 PRINTF.ASM	1993/12/06  02:00     632 PRINTF.ASM
1989/06/30  10:01  24,066 SCRN.ASM	1993/12/06  02:00   6,193 SCRN.ASM
1989/05/10  10:00   7,648 SMOOTH.ASM	1993/12/06  02:00   4,600 SMOOTH.ASM
1989/06/30  10:01  12,508 STRING.ASM	1993/12/06  02:00  18,237 STRING.ASM
					1993/12/06  02:00   7,607 SWAP.ASM
1989/06/30  10:01  20,063 TEXT.ASM	1993/12/06  02:00  30,587 TEXT.ASM
1989/05/10  10:00  14,278 VIEW.ASM	1993/12/06  02:00  15,723 VIEW.ASM
1989/06/30  10:01   8,754 WIND.ASM	1993/12/06  02:00   9,978 WIND.ASM
1989/05/10  10:00   4,789 XSCR.ASM	1993/12/06  02:00   7,061 XSCR.ASM

　少々マニュアルで編集しています。正確なデータが欲しい方は、ご自分でこんな
オタクな作業をなされるのが吉です。syoさんみたく、テキストと戯れるのが好き
なんですよ。
　僕も宵っぱり、なのかな。

　あのxxx.cgiとか、yyy.cgとかの中身が、うげげげげ、だったので、もっと
分りやすいのにしたい、と個人的に思いまして、４年ぶりのマクロです。syoテイスト
です。けっこう時間がかかります。&sとか消して確認しようとしたら、やってられん、
となりました。実際、台所の片付けに行きました。お当番日。
　そのうち、論理行の順番が入れ替わるという現象を見てみたいと思います。
　いやぁ、楽しかった。マクロ書き。いっぱいこけたのよ。

　ins.txtとrec.txtとかにしたい。インサートとレシーブと。模範解答は、ans.txtとか。
　挿入ファイルの論理行長は関係ないと。僕は（ほんと小さくして欲しいので）、
不具合発現のファイル最小サイズを知りたいです。もしかして、以下のような美しい
ファイルでは、不具合が発現しないとか……。あのログの呪い……。

　改行上でtop of lineしても、前の行には行かないと思うけどなぁ。読み間違ってるの
だろう。そのうち、エスキ２つ、読みます。


=== filemake.def by B ===;
; --- make files more than 64K bytes, each line with more than 5000, 6000, 7000 chars.
; ins.txtとかrec.txtのように空ファイル上で実行のこと（笑）。
; >type ins.txt rec.txt >ans.txt

* M
50 ^^ "Filemake"

p="01234567890123456789012345678901234567890123456789",				;50 chars x100
;p="012345678901234567890123456789012345678901234567890123456789",		;60 chars x100
;p="0123456789012345678901234567890123456789012345678901234567890123456789",	;70 chars x100

	i=1, j=1,			;i=local counter, j=global counter
	&s

:a	;--- make para (5000 chars)

	&m("%d 段落目を作成中だよ (^^)v",j)

	(i>100)? >b			;100 times:  50x100=5,000 chars in 1 para
	(i)?? { &?("【%02d】",j) }	; +6
	&?("%s",p)			;  60x100=6,000 / 70x100=7,000
	i++, >a

:b	;--- make file (5000x15=75,000 chars)

	ei[-, #m #m ei],
	j++, 
	(j>15)?? {i-, >a} 		;15 times: 5000x15=75,000 chars, w/ \n & mark = 75,900

:z	&d
	&m("【filemake】ヽ(^。^)ノ 終了！") .

*

--- zenhan.sed ---
# 全角文字を"00"に変更
s/[、-◯ぁ-んァ-ヶ亜-腕弌-龠]/00/g
------------------

>Sed32 -f zenhan.sed 0007.cg >0007_.cg		;(1)
>Sed32 -f zenhan.sed 0007.cgi >0007_.cgi	;(2)
>Sed32 -f zenhan.sed 0008.cgi >0008_.cgi	;(3)

>dir
2022/06/24  16:04        60 zenhan.sed
2022/06/18  23:00   132,553 0007.cg	;filesizeからして
2022/06/24  16:07   132,553 0007_.cg	;置換は無事できたのだろう

2022/06/18  23:00   302,888 0007-i.cgi
2022/06/24  16:08   302,888 0007_.cgi	;挿入成功したからこのサイズ
2022/06/18  23:25   170,335 0007.cgi

2022/06/24  16:05    31,369 0008.cgi
2022/06/24  16:08    31,369 0008_.cgi

　(2)に(1)挿入　成功
　(3)に(1)挿入　VTDOS 「ラップアラウンド」。
　すいません、WinMEでテストする気になりません。

　訳が分らないのは間違いありません。0008.cgiは0007.cgiに含まれているの
だもの。「訳が分らない」という結論は、はい、忘れていましたが、この
プロジェクトに参加する以前から（ほぼ経緯を知らなかったのに）知っては
いましたが。
　僕のアプローチは「地雷の近くには近づくな。地雷敷設位置だけ、ある程度
知っておけ。踏んじゃったら、しょうがない。命は取られないから大丈夫」
です。

> この問題に、ついに文太さんまで巻き込んでしまいましたね。

ＶＺの問題はみんなで共有した方がいいかと思ったもので。(^^;

> ところで、私自身はあまり文字化けには出会っていないんですよ。
> 全く出会っていない、というほどでもないのですが、再現条件をほとんど絞り込んでいません。

私も数回見ただけですが、もしかしたら文字化けは別の原因という可能性も考えています。

> 一方で、それよりも頻度が高いのが、ジャンプとかテキスト比較の場合に、カーソル位置が全く変なところに飛びまくる、という現象。なので、この辺からも、テンポラリファイルの処理がなんかこけているのではないかなぁ、と推測はしているのですがね。

行ブロックが入れ替わるという現象は、マクロが原因ではないかと思います。

トレースで見ると、3回目の #i のブロックペースト後が問題です。
 Ek- の時カーソル位置更新しますが、その位置が1文字ズレて改行の所になります。
本来なら行頭にくるはずなんですが、1文字ズレることがあるんですね。

ここで問題になるのがマクロの挙動です。

:C	#y (mb)?{ #W #< #i (ek)?? #B #W >C }
　　　　　　　　　　 ^^
ここの #< カーソルを論理行頭に移動するコマンドが余計なことをするのです。
#i の前にあるので、2回目以降の挿入後位置を行頭に移動します。

カーソルが行頭にあれば動かないですが、改行位置にあれば1行前の行頭に飛んでしまいます。
このせいで行ブロックが入れ替わってしまっていたのです。

このマクロは、c.mos さんが作ったので、必要があって #< を入れていると思われます。
これを取れば、行ブロックはズレないと思われますが、わざわざ入れている意味は？

もしかしたら、行頭より先の方にズレることがあるために入れているとか？
だとしたら、マクロの修正が必要ですね。

(cd==13)??#<

とか、どうですか？
え？　ソースを直せって？　それはまだ無理なんで。(^^;

I:\WW>dir

2022/06/18  23:00   132,553 0007.cg	;挿入ファイル
2022/06/20  23:51   302,888 0007.cgi	;オリジナル・エスキ＋konno修正で結合後　(ek[-, ek], added)
2022/06/18  23:00   302,888 0007-i.cgi	;正解
2022/06/20  23:50   302,888 x.txt	;typeコマンドでくっつけた

I:\WW>diff i:\ww\0007-i.cgi i:\ww\0007.cgi
 blank!

I:\WW>diff x.txt 0007.cgi
 blank!

　konnoマジックを読んでみたいと思います。
　とにかく、c.mosさんの入れた、マクロのバグだったと。
　ただ、ざっと見たところ、c.mosさんのマクロも、上村さんのマクロも、お手本ですね。
　だいたい読めたのが驚き。

　作業をダイジェストすると、挿入ファイルも被挿入ファイルも８０字で桁折りして
c.mos版エスキをしたら、どうなる？　ということ。
　結果。成功。
　やっぱり、きっと、論理行長が長すぎたのだろう。

------------------------ 80.sed ---------------------
# ８０字で桁折り。後のundoのため（連結）文尾にマーカーとして「＃＆あｓ」を付加。
# 見事にプリミティブなことに「.」は、80個。数え間違いがあっても、問題なし。
# >sed32 -f 80.sed 

s/\(................................................................................\)/\1＃＆あｓ\
/g
-----------------------------------------------------

I:\WW>sed32 -f 80.sed 0007.cgi >0007_.cgi 

I:\WW>sed32 -f 80.sed 0007.cg >0007_.cg 

 --- ここで、オリジナル・エスキ by Vz ---
 --- そして、文末マーキング外し by Vz ---

I:\WW>dir
2022/06/18  23:00           302,888 0007-i.cgi
2022/06/23  01:18           302,888 0007_.cgi

I:\WW>diff 0007_.cgi 0007-i.cgi
 blank!

I:\WW>sed32 --version
GNU sed version 3.02 + multi-byte extension 1.07

　serrow版では無理だったので、32bitのJapanizedされたsedを使いました。

　0007.cgi を 0007_.cgi に桁折りし（８０字）、同様に
　0007.cg  を 0007_.cg  に桁折りし（８０字）、konno修正を外した、オリジナル
エスキを施し、怖かったけどそれしか手がなかったので、Ｖｚの置換で、「＃＆あｓ\n」
という行末マークを外した（テキストバッファ、がんばれ！）。

　c.mos版エスキ（konno修正なし）も、この論理行長（８０字）ならちゃんと機能
しました。

　nagasa.defがこけた、ということだったので、やっぱり、その論理行長じゃ、Ｖｚ
には無理なんだろうと思ったので、この実験をしました。

　たぶん、過去ログ整理をしているとき、1MBくらいのファイルにエスキとかしていた。
insfile.def by Kamimuraだったはずだけど。問題なかったよなぁ、という記憶で。
ただ、niftyのログファイルは、論理行長がそんなに長くはなかった。

　アプローチを変えました。
　論理行はどのくらい長くても、Ｖｚは耐えられるのか？
　c.mos版オリジナル・エスキだけでなく、Ｖｚのいろんなところが。
（#Sとかnagasa.defとか置換とか）

　倍々で桁折り論理長を長くしてゆく。

2022/06/23     320  80.sed
2022/06/23     354  160.sed
2022/06/23     514  320.sed
2022/06/23     835  640.sed
2022/06/23   1,476  1280.sed	;こけた。1280*2 bytes (max)

　面倒なので少しでも省力化。以下は最終版。

--- go.bat ---
rem 1280
sed32 -f 1280.sed 0007.cgi >0007_.cgi 
sed32 -f 1280.sed 0007.cg >0007_.cg 
--------------

--- go2.bat ---
diff 0007_.cgi 0007-i.cgi
---------------
　not blank!!!

　go.bat、エスキ、置換（Ｖｚ）、go2.bat の順番で、【それぞれ】実行。
　１２８０文字ということは、最大で、2560 bytes。
　insfile.defなら問題ないが、original ESCIでは問題が出るのは、意外に
早い。

　まったく狙っていなかったのは容易に想像できるけど、上村さんの上位互換
マクロは、たぶんＶｚの名誉に大きく貢献した。（狙いはtc制限解除）
　とはいえ、１２８０文字というのは、４００字の原稿用紙で３枚以上も段落
なしの日本語原稿。ま、めったに作られませんね。

>挿入異常の原因も改行コードが原因だった、なんてことだったりして。

　元データの改行記号に不健全性があっては、けっこう大変かも、と思って
調べました。
　結論：問題なし

I:\WW>sed32 "" 0007.cgi >0007_.cgi

I:\WW>sed32 "" 0007.cg >0007_.cg

I:\WW>dir
2022/06/18  23:00           302,888 0007-i.cgi	;184
2022/06/18  23:00           132,553 0007.cg	;80
2022/06/18  23:25           170,335 0007.cgi	;104
2022/06/23  15:51           132,553 0007_.cg	;80
2022/06/23  15:51           170,335 0007_.cgi	;104

　sed32が何をしているかというと、typeしてます。ただ、sedはパターン
スペースに行を読み込み、改行を取るというように振る舞います。\nでなく\l
みたいな片割れが入っていたとき、どうするのか詳細は分かりませんが、きっと
取ります。排出時にまた付けます。
　で、「;184」とかは、「\n」→「\n」で改行の数をカウントした結果です。

　論理行長がＶｚにとっては（きっと）長すぎる、という点はあるとしても、
元データは改行に関しては、おそらく健全です。

　たぶん、これでお終いです。ごめん。

　ふと気になりました。ほんとに、ＬＦのみ、ＣＲのみで入ってきたテキスト
ファイルの出力も、ＳＥＤはＣＲＬＦにしてしまうのか？　結果：します。

I:\WW>sed32 "" test.txt >test_.txt

I:\WW>dir
2022/06/23  16:56           4 test.txt	;LFのみの４行、入力
2022/06/23  16:57           8 test_.txt	;sed の出力

（参考）
======== 0d0a.def ======== by I.Kamimura
#if 0
【改行コード統一】（Ｖz Ver 1.5-1.6 共用）
　● Mac の「^M」にも対応
より

        #56 "\n" #m "\l" #m "AY"        ; CR,LF --> LF
        #56 "\r" #m "\l" #m "AY"        ; CR --> LF

I:\WW>type test.txt >test_.txt

I:\WW>dir
2022/06/23  23:30                 4 test.txt	;4 LFs
2022/06/23  23:31                 4 test_.txt	;ditto

　うん、Japanized Sedの振る舞いは、type コマンドとは、
やはり違いますね。

　ちょこっと落書きです。あれ以来、すっかり sed にはまってます。

#>c:\sed42\bin\sed.exe [-n] -f c:\0try\006.sed c:\0try\006.txt

　以下、スクリプトは全て 006.sed
--------------------
#n                  #with -n cmdline option
/あああaaa/Ip       #I flagが偉いと言いたいだけです
--------------------# ignorecase, GNU sed 4.2 (?) or later

--------------------#without -n cmdline option
/あああaaa/I!d      #I flagが偉いと言いたいだけです
--------------------# cool!  GNU sed 4.2 (?) or later

--------------------
#n                  #with -n cmdline option
/あああaaa/p        #without I flag
/あああAAA/p        #most traditional (serow OK)
--------------------

--------------------
/あああaaa/b        #without -n cmdline option
/あああAAA/!d       #こういうのを勉強したり考えたりするのが
--------------------#楽しいと、病気です。(serow OK, too)

------ 006.txt -----
あああaaa
ddddddddd
あああAAAあ
--------------------

　もちろん、[c]grep -i "あああaaa" 006.txt でＯＫ．

https://ac206223.ppp.asahi-net.or.jp/adiary/memo/adiary.cgi/hirosugu/GNU%20sed%20%E3%82%92Windows%E3%81%A7%E4%BD%BF%E3%81%86

　*.dllとか面倒なのですが、どうやら昨今では、ロケールの判定みたいなのが自動
みたいで（？）、もう日本語への（マルチバイトへの）移植とか必要ないみたい。
　ごちゃごちゃしてますけどね。

C:\>c:\sed42\bin\sed.exe "" c:\test.txt >kek.txt
test.txt  4    2022-08-03  21:03	;4 \l's　(input)
kek.txt   8    2022-08-03  21:03	;4 \n's　(output)

　うん、日本語化というかS-JIS化というのか、出力はCRLFでした。

#>c:\sed42\bin\Sed -f c:\0try\002.sed c:\0try\002.txt

s/^\(..\).*$/\1\1\1\1/
s/^\(.\).*$/\1\1\1\1/		# freeze

--- input ---
あいうえお
-------------

--- output --
ああああ
-------------

　1999/06/20 12:41　99,854　GSED3.EXE　　;GNU 3.02 +m 1.07 (hgc02147)
　　　　　　　　　　　　　　　　　　　　 ; stack overflow in VTDOS, (dos)
　　※「\n」many places became possible in GNU 4.0.5 or later
　2005/08/24 06:32 311,296　OSED.EXE　　 ;GNU 4.1.4 +Onig 2.4.2  -r  -R
　2007/07/13 09:22 159,744　mbsed.exe　　;GNU 4.1.4 (Bruce.)　　 -r
　　　　　　　　　　　　　　　　　　　　 ; \{n,m\} OK
　2009/10/01 01:45 278,528　onigsed.exe　;GNU 4.1.5 +Onig 2.5.0  -r  -R

  実験しまくる冒険野郎さんは、下の３つでもいいかも。
  上のVTDOSでは使えない奴が、Windowsでは一般にお勧めなのかも。
  serowさんので行きましょう！　進歩ないねぇ。

C:\BIN>dir oldsed.exe
1988/03/02  06:11            15,366 OLDSED.EXE　　; by serow
　34年前の作品でしょうか。

>onigsed以外の選択肢はあるのかしらん？
　serowさんなら、けっこうどこでも。VTDOSとか。onigsedは、置換だけ
なら（これにすらいろいろ……）……、勉強用にはまったく向かないと思います。
　実用としては……。

>あ，そうか，dosvaxj3 環境だとセローさん
　logos sedも、ある場合には有益かも。

s/なんとか/かんとか\
/
　このs/regex/replacement/ の「/replacement/」で、\nが効かないのは、
きついです。logosでは効きます（アドレッシングの冒頭 /regex/ { でも）。
　s/abc/ABC/4の「4」も効きます。

　行志向の正規表現で、sedで、複行を扱おうとするから、こんな苦労をしてる
のですが、

----- 007.sed -----
# l コマンドおよび正規表現「.」が改行にマッチするかの実験
#Sed32 -f c:\0try\007.sed c:\0try\007.txt

$!N
l
s/^.../ABC/

----- 007.txt -----
あ
い
う

----- kek -----
C:\0TRY>Sed32 -f c:\0try\007.sed c:\0try\007.txt
あ\nい$		# 'l' による、パタ−ンスペース直視
ABC		# 【出力】「.」が \n にヒットしてる
う$		# パタ−ンスペース直視ふたたび
う		# 【出力】

　上は、serow, logosでは、これほど分かりやすくありません。serow, logos
でも、「.」は改行文字にヒットするのですが。

　32ビット+環境なら、
1999/06/20 13:40　90,112　sed32.exe　　;GNU 3.02 +m 1.07　（filename変えてます）
　がおすすめです。＠ベクター

　ああ、いえいえ。
　気づかせていただきまして。m(__)m

　僕のsed.shdには、以下の記述がありました。

　1999/06/20 12:41　99,854　GSED3.EXE　　;GNU 3.02 +m 1.07 (hgc02147)
　　　　　　　　　　　　　　　　　　　　 ; stack overflow in VTDOS, (dos)
　----------------------------------------------------------------------
　1999/06/20 13:40　90,112　sed32.exe　　;GNU 3.02 +m 1.07

　　※ filenameは、僕が勝手に変更しています。

　で、GNU sed 3.02 + multibyte 1.07 って、２種類あるみたいじゃん、と
気づきました。上の「GSED3.EXE」は、VTDOSでは使えなかったとあります。
ここのところ、vtdos @ win7で、破線下の sed32.exeをよく使っています。
とりわけ「stack overflow」とか言われることもなく。

　ただバイト数の違う、GNU sed 3.02 (Japanized)が２つあることに気づいた
わけです。

C:\0TRY>gsed3 --version
GNU sed version 3.02 + multi-byte extension 1.07

C:\0TRY>dir c:\bin\gsed3.exe
1999/06/20  12:41            99,854 GSED3.EXE

C:\0TRY>sed32 --version
GNU sed version 3.02 + multi-byte extension 1.07

C:\0TRY>dir c:\bin\sed32.exe
1999/06/20  13:40            90,112 sed32.exe

　このように、僕のミスではない。僕には、こんな実行ファイルをコンパイルとか
できませんから、どっかから（ベクター以外ありうるのか？）落としてきたに
違いありません。
　というわけで、わりと調子いいのは、dirコマンドの結果では下にきている
90,112 bytes サイズのほうです。

　DOSエミュレータ環境に執着しているのではなくて、32bit sedは
いろいろ敷居が高いから、この辺で、という意図です。
　欲張らずあるもので足らそう。

　何が足りなくて気に入らないのだっけ？
　そんなにいろんな種類をコレクションしちゃって……。
　整理しました。あったりなかったりする（困る＜気になる）
features は以下です。

　こういうのもありました。for DOS.
C:\>dsed --version
GNU sed version 1.18 + multi-byte extension 1.03

C:\>dir c:\bin\dsed.exe
1994/06/02  19:17            70,111 dsed.exe

【結果】
		serow	logos	dsed
\t		OK	OK	NG
\s		NG	NG	NG
\{n,m\}		NG	NG	OK
s/LHS/RHS/2	NG	OK	OK	;Nth flag
\n in RHS	NG	OK	NG	;s/LHS// で\nが使えなかったら複行を扱えない
\|		NG	NG	OK	;or
\+		NG	NG	OK	;more than once

【実験・調査】
C:\>echo "	" | oldsed "s/\t/aaa/"	;white space is tab, OK
"aaa" 

C:\>echo "	" | lsed "s/\t/aaa/"	;OK
"aaa" 

C:\>echo "	" | dsed "s/\t/aaa/"	;NG
"	" 

C:\>echo "aaa" | dsed -n "/a\{5\}/p"	;OK
blank

C:\0TRY>echo "aaa" | dsed -n "/a\{3\}/p"	;OK
"aaa" 

C:\>echo "aaa" | dsed -n "s/a\+/bb\ncc/p"	;\n -> n, NG
"bbncc" 

C:\>echo "aaa" | lsed -n "s/a\+/bb\ncc/p"	;\+ NG
blank

C:\>echo "aaa" | lsed -n "s/aaa/bb\ncc/p"	;\n in RHS, OK
"bb
cc" 

C:\>echo "aaa" | lsed -n "s/a/b/2p"		;Nth flag, OK
"aba" 

C:\>echo "aaa" | dsed -n "s/a/b/2p"		;OK, too
"aba" 

C:\>echo "aaa" | oldsed -n "s/a/b/2p"		;NG
sed: command "s/a/b/2p" has trailing garbage

--- command.com があれなので、以下はスクリプト＋対象ファイルで

C:\0TRY>type 002.sed
#Sed32 -n -f c:\002.sed c:\002.txt
#OR (\|) test
/abc\|def/p

C:\0TRY>type 002.txt
abc

C:\0TRY>Sed32 -n -f c:\002.sed c:\002.txt	;OK
abc

C:\0TRY>dSed -n -f c:\002.sed c:\002.txt	;OK
abc

C:\0TRY>oldSed -n -f c:\002.sed c:\002.txt	;NG

C:\0TRY>lSed -n -f c:\002.sed c:\002.txt	;NG


　GNU extensionとしては、\<, \>, \+, \|, \b, \B, \`, \'
があるみたいでした。


https://www.pement.org/sed/index.htm
Table of features in DOS and Windows versions of sed
　あまり参考になりません。日本語を処理してくれないと、なので。

　いちおう修正しておきます。

　　dos版比較
　　　　　　　　　serow　 logos　 dsed　sed32
　\t　　　　　　　OK　　　OK　　　NG　　NG
　\s　　　　　　　NG　　　NG　　　NG　　NG
　s/LHS/RHS/2　　 NG　　　OK　　　OK　　OK
　\n in RHS　　　 NG　　　OK　　　NG　　NG
　\{n,m\}　　　　 NG　　　NG　　　OK　　OK
　\+　　　　　　　+　　　 +　　　 \+　　\+
　\|　　　　　　　NG　　　NG　　　OK　　OK

　めざらさん宛ではありません。
　ま、sedでアートを極めようとおもったら、dsed.exeかsed32.exeがいいのでしょう。

C:\0TRY>dsed --version
GNU sed version 1.18 + multi-byte extension 1.03

C:\0TRY>sed32 --version
GNU sed version 3.02 + multi-byte extension 1.07

　このような版です。
　バグのないプログラムはないのでしょう。でも、少ないほうがいいよね。

-----
#Sed32 -nf c:\0try\001.sed c:\0try\001.txt
				#いちおうコメント付けますね。
				#でも、こんなコメントはふつう通りませんからね。
1!G				#1行目以外はＨＳの文字列をＰＳ文字列にアペンド
h				#ＰＳ文字列をＨＳに保存
$p				#最終行でＰＳ（反転された全行）を出力
-----

　これはファイル内の行を反転させるtacのsed版です。何に使うの？　
ファイル末近辺の行に何かするというのは、一般に大変なのです。だから
行を反転させて、ファイル先端で処理をすると楽、ということがある。

　上は芸術です。読めると、な、な、な、なるほど！　となります。

-----
A
B
C
-----
が
-----
C
B
A
-----
　となる。コマンドがたったの３つだけ。でもこれができちゃう。

　が、これがserow版とlogos版ではこけるのです。sedの基本文法に反することが
一つもないスクリプトなのに。Gかhにバグがあるんだろうと思う……。
　sedって、DOS, Windowsで、あまり使われてこなかったツールなんでしょうね。
　置換だけだものねぇ、ふつう使うの。

　四方山話をもう一つ。もちろん、sedがらみです。

　ファイル末に改行がないファイルって、ときどき作ってしまいますよね。
　で、ファイルの最終行が改行で終わってなかったら改行を付けよ、というプログラム
を書くということを、昔Siさんの掲示板でやりました。某としきさんは、Ｃで専用の
プログラムを書いてくれました（じつは手元にまだあります）。
　これを先日、sedで書けないか、と思っていろいろ試したのです。[^\n]とか'$'とか
いろいろ苦労した。

　結論：

>sed "" 対象ファイル > 結果ファイル
　おしまい。

　誰も興味ないでしょうけど、簡単に解説。
　sedは制御フローを変更したりしないと（高度なコマンドを使うことになります）、
awkと同じく、入力ファイルの各行を順にパターンスペースの読み込みます。で、この際、
行末の改行をとって処理し、そして、改行をつけて出力する。これを繰り返すわけです。
だからパターンスペースの中には、ふつうの状態では、'\n'は存在しない。
　で、入力行に改行がなくても同じ動作をする。つまり、出力の際に改行をつけてしまう。
（\l -> \n の変換もしてくれる、してしまう）。

　というわけで、ファイル末に改行のないファイルでも、付けて２バイト、ファイル
サイズの太ったものが出力されます。
　逆にいうと、ファイル末に改行のないファイルはsedの出力ではありえないのです。

sedって奴は……

　あの、…………。
　いいよ、もう何も言うな。

　以下のように、コマンドライン・オプションの与え方でも、昔は、きっちり
機械のように何回もやってもらわなければならぬ、ということだったようです。
　いや、G と h のどっちにバグがあるのか調べてやろうとか、少し時間が
あいたら、思ってしまって。
　まとめてオプションを書いてはならぬ、ということです。


C:\0TRY>Sed32 -nf c:\0try\004.sed c:\0try\004.txt
2
1

C:\0TRY>dSed -nf c:\0try\004.sed c:\0try\004.txt
2
1

C:\0TRY>oldSed -nf c:\0try\004.sed c:\0try\004.txt
:0try004.sed
:0try004.sed

C:\0TRY>lSed -nf c:\0try\004.sed c:\0try\004.txt
:0try004.sed
:0try004.sed

C:\0TRY>lSed -n -f c:\0try\004.sed c:\0try\004.txt
2
1

C:\0TRY>oldSed -n -f c:\0try\004.sed c:\0try\004.txt
2
1

0007.cgi  170,335  2022-06-18  23:25
から、ファイル末尾から適当に削って、以下を得た。

000.cgi    29,685  2022-06-29  20:48
　27,931 bytes が目標。

（このあと微妙に削っていくつもりだったので、ファイル名を
連番にした。するつもりだった。しかし、最初に実験が失敗して
しまった……。）


--- test.awk ---
#各段落の長さ（bytes）を表示

{ printf("%d	%d\n",NR,(length($0))) }
----------------

>gawk -f test.awk 000.cgi >kek.txt
　すると、以下のような具合。

1	1501
2	822
3	1513
4	3703
5	4214
6	1794
7	1393
8	1824
9	1867
10	984
11	655
12	2501
13	723
14	2138
15	4023


0007.cg 挿入後（もちろん、オリジナル・エスキ使用）
000.cgi  162,238  2022-06-29  20:51

　こうなった。ファイルの中身というのを確認する習慣がないので
異常挿入なのかどうかは分りませんが（段落の順番が入れ替わるなど
未経験）、少なくとも窓もＶｚも飛びません。
　僕の視点（経験）からすると、挿入成功なのですが、手順が間違って
いないことだけ確認させていただけますか？

　ところで、としきさんが「異常挿入」と言うばあい、挿入自体はされ、
Ｖｚ、窓などが飛ぶということはないのですか？
　僕が挿入失敗したとき（そう言ったとき）、だいたい窓が飛ぶか固まるか、
マシン・フリーズしていたのですが。

　最小サイズを再確認してみようという、つもりでした。

　いちおうここにぶら下げます。


　元々、0007.cgiの最小サイズを俺も調べてやる（きっと値は違うだろうけど）と
着手した実験でした。目的は、曖昧に、「最小サイズが決まる」という事実を
確認すること。

　前回失敗したので、0007.cgiから頭１７行（たしか）をとり、これを000.cgiとし、
あらかじめ、typeコマンドで模範解答を用意しておき、000.cgiに0007.cgを挿入。
　結果できたのが、下の上。

000.cgi  162,238  2022-07-02  15:37	;すいません、挿入の結果ファイルです
000_.cgi 162,238  2022-07-02  15:36	;あらかじめ作っておいた模範解答ファイル
					;困ったことにサイズが同じ。

>diff
　だらだらだらだら。

　おお、サイズが同じなのに、相違を出してくる。（つまり飛んでない！）
　では、どう違うのか調査。
　Ｖｚでの比較。違う箇所はいちおう特定できたけど、やだ、このログ、読みづらい、と
別の作戦に変更。awk作戦

--- line_len.awk ---
{ printf("%d	%d\n",NR,(length($0))) }
--------------------
　これで、上記２つの結果ファイルの行番号と行の長さを出し、これをＶｚで比較


>gawk -f line_len.awk 000_.cgi >kek000_.txt

--- kek000_.txt ---	;こちらは模範解答

1	3970
2	1200
（中略）
77	1069	;(1)
78	2551	;(2)
79	1246	;(3)
80	2040	;(4)
（中略）
81	1501
82	822


　下が、オリジナル・エスキによる結合ファイルの行の状態。

>gawk -f line_len.awk 000.cgi >kek000.txt

--- kek000.txt ---

1	3970
2	1200
（中略）
77	1069	;(1)
78	1246	;(3)
79	2040	;(4)
80	2551	;(2)
（中略）
81	1501
82	822

　ブロックポインタが１バイトずれるだけで、これだけのカオスって起きるの
でしたっけ？　僕の誤解？　konnoさんの修正を見たときに、１行だけ反転するのか、
とか空想したのですが……。
　窓が飛んだりするのは、別の原因なのかな？　Ｖｚの、あるいはＶＴＤＯＳの。
（僕のＶＴＤＯＳ環境が脆弱なのだろうと想像しています。Ｖｚのステータスバーが
リードオンリーの青になり、固まる、というのを今日、経験しました。これ、Ｖｚが
固まっているのだと思う。）

　ああ、またしても、時間切れ、あるいは力尽きて、目的の場所までたどり着け
ませんでした。ほんと、次から次に多重出現。

　読んでます。多謝。後日レスします。熱中症になりました。ヘロヘロ。ご自愛
ください。畑仕事には、くれぐれもご注意を。

　結果だけ報告します。
　１６行の被挿入ファイル（0008.cgi）に、８０行のファイル（0007.cg）を
挿入すると、結果ファイル（挿入後の大きなファイル）の７８、７９、８０の行で、
行反転が起こります。つまり挿入ファイルの末尾でだけ行反転が起こる。
　なぜコピーの最後でだけ起こるのでしょうか？
　ブロックポインタが最後だけずれるのは、論理的でしょうか？
　もっとシステマタィックに（規則的に）ずれるだろう、行反転も規則的に起こる
だろうと思っていたのです。
　いえ、ちょっと驚いただけですなんですが。

　この実験は前回に同じく、模範解答と実験結果ファイルのファイルサイズが同一
という、一見挿入成功に見える場合に発生しました。この不具合発現には、再現性が
あるように感じてます。

--- 模範解答 ---
77	1069
78	2551	;　A
79	1246	;　B
80	2040	;　B
81	1501
----------------

--- 挿入実験 ---
77	1069
78	1246	;　B
79	2040	;　B
80	2551	;　A
81	1501
----------------
　左端の２ケタ数字はＮＲというか行番号。
　右側の４ケタ数字は論理行長。

　経験的に（笑）、2551とかって、決して長すぎるというわけでもないと思う。
1246+2040とかの長さが関係している？


　あてにはなりませんが、「１６行」のファイルを１５行、１４行と減らしていくと
不具合は出ず、逆に１７行、１８行と増やしていくと、やがて行反転どころかＶｚが
あるいはＶＴＤＯＳが飛ぶ、ということになるように感じています。含まれる行の長さ
も関係してるのかなぁ。

　熱中症はやがて腰が痛くなります。現在、そのフェーズです。

　まあ、insfile.defを使えばいいのだし、という最初に戻ってしまうのですが。
　「どこで不具合は出始めるのか？」というのをポイントにしました。
　まず

--- 1.bat ---
rem get n line(s) files		(1.bat)

sed32 -e "1q"	0007.cgi > 01.org
sed32 -e "2q"	0007.cgi > 02.org
sed32 -e "3q"	0007.cgi > 03.org
sed32 -e "4q"	0007.cgi > 04.org
sed32 -e "5q"	0007.cgi > 05.org
sed32 -e "6q"	0007.cgi > 06.org
sed32 -e "7q"	0007.cgi > 07.org
sed32 -e "8q"	0007.cgi > 08.org
sed32 -e "9q"	0007.cgi > 09.org
sed32 -e "10q"	0007.cgi > 10.org
sed32 -e "11q"	0007.cgi > 11.org
sed32 -e "12q"	0007.cgi > 12.org
sed32 -e "13q"	0007.cgi > 13.org
sed32 -e "14q"	0007.cgi > 14.org
sed32 -e "15q"	0007.cgi > 15.org
-------------
　これで、１行目のみのファイル（01.org）、１行目と２行目のファイル（02.org）
と１５個まで作りました。ほんとは２０個だったのだけど、１９行、２０行でawk
が鳴きました。--- ２０行目あたりに地雷がありそうな感触でもあった。

　（sedスクリプトを解説すると、「1q」は、１行目でQuitです。高速です。ただ１行目
は読み込んでからＱｕｉｔ命令＝以降ストップ、２行目は読み込みもしない、なので、
１行目だけは出力されます。）

　以下は、オリジナルエスキで、0007.cgを挿入したあと。（以前に１５個のファイルを
別ディレクトリーにコピーしておいて、>ren *.org *.txt しました）

2022/07/02  20:32           134,056 01.txt
2022/07/02  20:33           134,880 02.txt
2022/07/02  20:33           136,395 03.txt
2022/07/02  20:33           140,100 04.txt
2022/07/02  20:33           144,316 05.txt
2022/07/02  20:33           146,112 06.txt
2022/07/02  20:34           147,507 07.txt
2022/07/02  20:34           149,333 08.txt
2022/07/02  20:34           151,202 09.txt
2022/07/02  20:35           152,188 10.txt
2022/07/02  20:35           152,845 11.txt
2022/07/02  20:35           155,348 12.txt
2022/07/02  20:35           156,073 13.txt
2022/07/02  20:35           158,213 14.txt
2022/07/02  20:36           162,238 15.txt	;ここで反転おきた。#4850の奴

--- 15.len ---; 15.txtの論理行長（抜粋）
75	759
76	796
77	1069	;(1)
78	1246	;(3)
79	2040	;(4)
80	2551	;(2)
81	1501
82	822
--------------


　原因追求にまったく向かってませんが、これ以降ではもう何が起こるかわからん、
という感じです。
　正解ファイルをtypeで作っておく、line_len.awkで、各状態のときの行の長さを
調べておく、diffで差異を外からみる、などしましたが（６個のバッチファイル）、
うーん、もうダメ。

　15.txt, 16.txt, 17.txt, 18.txtに対して、0007.cgをどこまで小さくすれば……。
　あんまりやる気になってませんねぇ。

　このレベルの作業では、VTDOSが鳴くことはなかったと思う。ピカっと光るのは、
今日は未経験。前に書いたかもしれませんが、Ｖｚのステータスバーがリード
オンリー時の青に変わって、Ｖｚが固まるのは、１６行目、１７行目あたりで経験
したと思います。
　なんとなく調査範囲を限定したので、割とＶｚの反応（ＰＣの反応）は、ＰＣらしく
機械的でした。たとえ時にかたまるにせよ。

追伸

　大昔の話ですが、僕は結局niftyのログファイルはけっこう小さめに刻みました。
たぶん、１ＭＢくらい。ログを修正したくなるときがあったりするし。
　でも、もちろん論理長は長くはない。

in.ejr  4,389,608  2017-03-29  23:06

　これがきっと扱うことのある割と大きめのファイルです。４メガ。辞書『英辞郎』
のファイルを切り刻んだもの。ただ、ファイル属性をリードオンリーにしてるから、
Ｖｚマクロで開けるのですが（グレップではなく）、トラブったことはないです。
中身は（論理行長は）短いです。
　一定の論理行長を超えると、いろんなところでいろんなことが起こる（詳細不明）
という、生き残るための知恵は身につけちゃってますね。MS-DOSのエディタとか、
いまどき（死ぬまで）使ってるのだし。serow版のsedも、あのログファイルに鳴きを
入れてました。
　「思わず使いたくなっちゃう」という状況にあまり遭遇しないのもラッキーなんで
しょうね。

　ちがう。15.txt, 16.txt, 17.txtあたりでのＶｚの反応はけっこう規則的でした。
ピンポイントに「ここから不具合が発現する」と特定はできませんでしたが。
　これが書きたかったのです。
　

各ファイルの最大論理長（エスキで挿入後）

　以下を使用して、0007.cg 挿入後のファイルから
--- lmax.awk ---
# lmax.awk; get maxlength info
{ if (maxlen < $2) {maxlen=$2} }
END { print maxlen }
----------------

　以下を得た。
----------------
01.txt	1501
02.txt	1501
03.txt	1513
04.txt	3703
05.txt	4214	;
06.txt	4214
07.txt	4214
08.txt	4214
09.txt	4214
10.txt	4214
11.txt	4214
12.txt	4214
13.txt	4214
14.txt	4214
15.txt	4214	;0007.cgi の 15論理行までのファイル
		;における最大長行
----------------


--- 15.len ---; 15.txtの論理行長（抜粋）
75	759
76	796
77	1069	;(1)
78	1246	;(3)
79	2040	;(4)
80	2551	;(2)
--------------

　ファイル挿入の場面そのもの（２つのファイル結合部）で、Ｖｚ（マクロ）の
不具合は発現していて、4214 bytesの行とか、あまり問題になっていない。
１つのポイントだとは思います。
　ゴミの累積とかはあるのかなぁ？
　ただ、やがて（20.txtぐらい？）で、ハングアップになるのですが。

>ところでBlって、１バイト単位で変化させられるのでしょうか。それとも256バイト単位？

　あはははは。
　おもしろい！　ざぶとん、１枚。

main.asm      238:GDATA lbufsz,	dw,	1024		; Bl

　1024 bytes 単位に１票。甘いか。そんなに調子よく丸めたりはしませんか。
　実験はなしです。

　#4889 の実験を vtdos@Win7 でもやりましたが、何を間違ったか結果が同じでした。
　呪われていると思うので、僕は、そっちは撤退です。はい、心が折れました。

2022/07/28  14:52     257 000.txt		;bl256
2022/07/28  14:54     261 000.txt		;bl260

　000.txtを「111111 ...」という内容で作る。
　ｂｌ２５６のときと、ｂｌ２６０のときの最大長行を求める＝「ラインバッファ
がいっぱいです」まで「1」の文字を書き込む。
　結果が上です。改行取られますから、きっと正確です。
　副作用がないかは分かりません。bl256では、動かないマクロ多数でした。

　きっと実験が面倒になりましたね。

--- vz.def ---
;Bl8192			;line buf (256..(Bt*1024/8))
Bl256			;line buf (256..(Bt*1024/8))
;256が最短とみました。
--------------


　昨晩、以下のようなことをしました。inst.asmあたりで、vz.defから読み込んだ
値を【lbufszに】入れるのだろうと思ったけど、そうじゃないみたい。あるいは、
調べ方、読み方が甘い、のでしょうね。

Ygrep "lbufsz" c:\vzsrc\cmos
c:\vzsrc\cmos\main.asm      238:GDATA lbufsz,	dw,	1024		; Bl
c:\vzsrc\cmos\main.asm      977:	mov	ax,lbufsz

c:\vzsrc\cmos\memo.asm       26:	extrn	lbufsz		:word
c:\vzsrc\cmos\memo.asm      758:	add	ax,lbufsz
c:\vzsrc\cmos\memo.asm      825:	cmp	ax,lbufsz
c:\vzsrc\cmos\memo.asm      828:	add	ax,lbufsz

c:\vzsrc\cmos\open.asm       36:	extrn	lbufsz		:word

c:\vzsrc\cmos\text.asm       37:	extrn	lbufsz		:word
c:\vzsrc\cmos\text.asm      808:	sub	cx,lbufsz
c:\vzsrc\cmos\text.asm      855:	sub	cx,lbufsz
c:\vzsrc\cmos\text.asm     1384:	add	ax,lbufsz
c:\vzsrc\cmos\text.asm     1467:	add	ax,lbufsz
c:\vzsrc\cmos\text.asm     1513:	sub	cx,lbufsz
c:\vzsrc\cmos\text.asm     1569:	sub	si,lbufsz

　微妙に違うみたいです。

>2266桁で桁折した場合には異常挿入は発生せず。
>一方、2267桁で桁折した場合は異常挿入発生。


fold -2266 0007.cgi >00071.cgi	;NG (行入れ替え)
fold -2265 0007.cgi >00072.cgi	;OK

2022/07/09  16:42   302,938   00071.cgi
2022/07/09  16:44   302,938   00071.ans		;模範解答
2022/07/09  16:46   302,938   00072.cgi
2022/07/09  16:45   302,938   00072.ans		;模範解答



I:\WK6>which fold.exe
C:\BIN\fold.exe

I:\WK6>dir c:\bin\fold.exe
 c:\bin のディレクトリ
1999/11/11  00:00            21,504 fold.exe

　どっから来たのだろう？

としきさん

　多謝。さすがです。

E:\>strings fold.exe >kek.txt

--- kek.txt 中身、有意味部分 ----
!This program cannot be run in DOS mode.	;32bit ものなのか？

standard output.
  -b, --bytes         count bytes rather than columns
  -s, --spaces        break at spaces
  -w, --width=WIDTH   use WIDTH columns instead of 80
      --help          display this help and exit
      --version       output version information and exit
Report bugs to <bug-textutils@gnu.org>.

Copyright (C) 1999 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---------------------------------

　GNU, textutilsだったのですね。ということは、やはり２バイト文字の認識とか
無理なんだ（たしかアスキーものは、なんとか判別するらしかった）

　strings.exeがアスキーのものらしく、Win7でStack overflow とか言ってて、これ
のためだけに、WinMEに来ました。
　DOS modeでダメってことは、

---------------------------------
E:\>fold --version
fold (GNU textutils) 2.0
Written by David MacKenzie.

Copyright (C) 1999 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---------------------------------

　はい、WinMEドス窓ではＯＫです。
　ふと思う。David MacKenzieさんは、きっと無償でこれを世界に提供した。そんな
方々をVillage Centerは、日本に紹介してた（Ｖｚ以前）。特殊で高い能力がみんなの
ために、という方向に向けられた時代は終わったのですね。マイクロソフトがイケナイ！
全部、金、金、金、金、金！！！

　冷静になって。
　strings.exe,　すげえ。ほぼ初めて有効な使い方ができた。

---------------------------------
E:\>strings e:\trash\strings.exe
DOS 2.0 or later required
error 2000: Stack overflow
error 2003: Integer divide by 0
error 2002: Floating point not loaded
C Library - (C)Copyright Microsoft Corp 1985
Usage: 
 [-<n>] [-jo] [ file [+[x]<n>[k]] ] ...
---------------------------------

　アスキーのものだと思うのだけど、どっかに書いておいてもいいのに。


STRINGS (2)	ファイル内の可読文字列の表示
　STRINGS　　ファイル内の可読文字列の表示

書式	STRINGS　［-<n>］［-jo］　［<ファイル名>　［＋［x］<n>［k］］］…

機能
　<ファイル名>で指定されたファイル中の，表示可能な連続した<n>文字以上
(デフォルトは4)の文字列を表示します．なお，文字列は改行文字(0DHまたは0AH)
もしくはヌル文字(00H)で終了していなければなりません．また，タブおよび
全角文字はこれを1文字と数えます．ただし，-jオプションが指定されていない
場合，全角文字および半角カタカナはこれを可読文字とは解釈しません．


　これが著作権に対する良心の限界です。下がもっと面白いのだけど。

what.exe exists!  in ASCII Tools

C:\>what c:\bin\fold.exe		;残念。以下のようにはいかなかった。
c:/bin/fold.exe:			;これは32bit GNU ものなので、表記の
					;慣習が変わったのだと思う。
					;これが事の発端。

C:\>what strings.exe
strings.exe
        strings.c  1.2 (Maison) 1/27/87	;Maisonさんに著作権がある？

C:\>what what.exe
what.exe
        what.c  2.3 (ASCII) 4/27/88	;ASCIIが著作権を持ってる？

C:\>strings what.exe
DOS 2.0 or later required
@(#)what.c      2.3 (ASCII) 4/27/88	;ここを表示

C:\>strings strings.exe
DOS 2.0 or later required		;msdosは、だいたい v.2.0で完成した
@(#)strings.c   1.2 (Maison) 1/27/87	;ということだと思う


　空想するに、Ascii Tools 3 のドキュメントがうちでは失われているらしい。
　すごいたまたまで、見つけました。　多謝＞としきさん

　上は、WinMEです。こっちがメインだけど、何かをアセンブルとかする気には
まったくなりません。あくまでテキスト処理用です。

　ここにぶら下げます。

【うちの結論】
　僕のところでは（Win7 + VTDOS）、

　0007.cgi は、最初の１５行のファイル
　と
　0007.cg そのもの

　の組み合わせで発現するとの結果を得ました。

　正確に言うと、0007.cgのほうは、これは80行のファイルなのですが、79行でも発現
します。が、ま、そのままで。

15.txt    29,685  2022-07-03  21:07	; １５行ファイル
0007.cg  132,553  2022-06-18  23:00	; ママ

15.txt   162,238  2022-07-03  20:57	; エスキ後

　これで、Ｖｚが飛ぶことなく、

78,80c78,80
< 78	1246
< 79	2040
< 80	2551
---
> 78	2551
> 79	1246
> 80	2040

　といった具合に、挿入ファイル（0007.cg）の末尾で行反転みたいなことが
起こります。この部分が起こるときだけ、マクロをトレースしたいのですが、
余力なし。

　16, 17, 18, 19, 20 行のファイルでは？　安定しないんです。17-20に関しては、
無事故のこともありました。
　ご存知のとおり、20.txtは（その他も）、15.txtを含んでるんです。なんなんですか？

　話の順番が前後しますが、僕は、0007.cgiの最小値を求めてから、0007.cgの最小値
を求めようとしました。0007.cgiはそのままで、0007.cgを小さくしていったら、違う
結果が出ていたのかもしれません。

　さて、見つけ方。簡単。面倒だけど。まず、（同じやり方なら）あたりをつける。
1.txt, 2.txt, 3.txt ... とかムダです。15.txt, 16.txt, 17.txt あたりからアプローチ
してください。

　以下は、15.txtを作る場合。


sed32 "15q" 0007.cgi	>15.txt
　15.txt 出来上がり。

　調査。まず正解を得ておく。
REM  get the correct answer file
type  0007.cg  15.txt  >  15.ans

　エスキする。

　その結果と模範解答（15.ans）を比べる。
REM  get the difference
diff  15.txt  15.ans  >  15.dif

　15.difが０バイトなら外れです。同一ファイルになってる。16.txt作成に戻る。
　０バイト以上で、こんなの何がどう違うのか分らん！　という人は下へ進む。

REM  record line length 1
gawk -f line_lst.awk 15.txt > 15.tsl
gawk -f line_lst.awk 15.ans > 15.asl

--- line_lst.awk ---
{ printf("%d	%d\n",NR,(length($0))) }
--------------------

　こうして、２つの行番号と行長のリストが得られた。

　比べてみよう。
REM  get the difference	from listfile
diff  15.tsl  15.asl  >  15.dif


　お疲れ様でした。で？　
　で？　の先はありません。

>> 異常挿入を起こす0007.cgiの冒頭からの真の最小のファイルサイズ
>見つけました。
>27932バイトでは異常発生、27931バイトでは正常挿入。

　はい、どんぴしゃにこの数字でした。Win7, Bl=8192です。
　0007.cgは、もちろん元のサイズです。なんなんだ、この数字は？
　めざらさんにも分らない。僕に分かるわけがない。
　でも、驚き。

151.txt  27,931  2022-07-07  14:55	;+"a"とかして１バイト増やしたりもした。
					;そしたら、異常挿入（行入れ替え）
　「虫の発生などは」がログ末尾。
　「虫の発生などはa」でも
　「虫の発生などaは」でも、異常挿入

　落ちないの分ってるから、いちおうWinMEでもやってみよう。
　もちろん、結果は同じでした。
　16.txtに関しては、Win7(VTDOS)とWinMEでは挙動（見栄え・手応え）が違いますが、
いずれにせよ異常挿入です。Win7=窓フリーズ、WinME=素直な（？）異常挿入。