新着記事

　こんな長い行を扱うことになるとは……。
　そして日本語化はどうなってたっけ？　というわけで、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
----------------------------------------------------------------------

　ここにぶら下げます。

【うちの結論】
　僕のところでは（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.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ぐらい？）で、ハングアップになるのですが。

追伸

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

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

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

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

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

　結果だけ報告します。
　１６行の被挿入ファイル（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とかの長さが関係している？


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

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

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


　元々、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さんの修正を見たときに、１行だけ反転するのか、
とか空想したのですが……。
　窓が飛んだりするのは、別の原因なのかな？　Ｖｚの、あるいはＶＴＤＯＳの。
（僕のＶＴＤＯＳ環境が脆弱なのだろうと想像しています。Ｖｚのステータスバーが
リードオンリーの青になり、固まる、というのを今日、経験しました。これ、Ｖｚが
固まっているのだと思う。）

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

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