新規投稿は記事一覧のフォームからお願いします
こんな長い行を扱うことになるとは……。 そして日本語化はどうなってたっけ? というわけで、Vectorとかで調べてDLして。 こんな連中と(様さまと)、お付き合いいただこうか、という次第です。 mawkは、いろいろとうまくいきません。>2バイト文字が混在するファイルの場合、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 ----------------------------------------------------------------------
> いちばん軽度の行入れ替えは、いちいち確認してませんよね。
> 業務運行をするなら、とりあえず再起動がお勧めな状態なのかもしれませんが。
> 僕のところでの「異常」のパターンは、以下の4種類。
> 調子こいて、両方のファイルを2048桁で桁折した場合も正常挿入。
> また、2048桁の.cgiファイルに4096桁の.cgファイルを挿入した場合は正常挿入。
> 上記のとおり、27932バイトのファイルで異常が発生しています。
> そこで、ためしに2048バイトで桁折してみました。
> でも、(中略)無事に?異常挿入。
> はあ? あの掲示板ログにはVzが扱えないS-JIS以外の「文字」が入っている可能性ってあるんですか?
> 3つ目の場合、4つ目の原因とか、まだあるのかも。
>再び文字コードとかの問題に戻ってしまう。
>何がなんだか。
ここにぶら下げます。 【うちの結論】 僕のところでは(Win7 + VTDOS)、 0007.cgi は、最初の15行のファイル と 0007.cg そのもの の組み合わせで発現するとの結果を得ました。 正確に言うと、0007.cgのほうは、これは80行のファイルなのですが、79行でも発現 します。が、ま、そのままで。 15.txt 29,685 2022-07-03 21:07 ; 15行ファイル 0007.cg 132,553 2022-06-18 23:00 ; ママ 15.txt 162,238 2022-07-03 20:57 ; エスキ後 これで、Vzが飛ぶことなく、 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が0バイトなら外れです。同一ファイルになってる。16.txt作成に戻る。 0バイト以上で、こんなの何がどう違うのか分らん! という人は下へ進む。 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))) } -------------------- こうして、2つの行番号と行長のリストが得られた。 比べてみよう。 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) -------------- ファイル挿入の場面そのもの(2つのファイル結合部)で、Vz(マクロ)の 不具合は発現していて、4214 bytesの行とか、あまり問題になっていない。 1つのポイントだとは思います。 ゴミの累積とかはあるのかなぁ? ただ、やがて(20.txtぐらい?)で、ハングアップになるのですが。
>飛んでいない、というのは、VzもしくはDOS窓のことですよね。
>つまり、システムが飛んでいない、という意味ですよね。
>あと、以前のお話では、システムが飛んでいないときはほぼ正常挿入だった
>ということでしたが、今度は相違があるということですよね。
>diff
>すると、何を、またはどこを、変更されたのでしょうか。
> おお、サイズが同じなのに、相違を出してくる。(つまり飛んでない!)
> 僕はあれらの光景をほぼ見たことがありません。
追伸 大昔の話ですが、僕は結局niftyのログファイルはけっこう小さめに刻みました。 たぶん、1MBくらい。ログを修正したくなるときがあったりするし。 でも、もちろん論理長は長くはない。 in.ejr 4,389,608 2017-03-29 23:06 これがきっと扱うことのある割と大きめのファイルです。4メガ。辞書『英辞郎』 のファイルを切り刻んだもの。ただ、ファイル属性をリードオンリーにしてるから、 Vzマクロで開けるのですが(グレップではなく)、トラブったことはないです。 中身は(論理行長は)短いです。 一定の論理行長を超えると、いろんなところでいろんなことが起こる(詳細不明) という、生き残るための知恵は身につけちゃってますね。MS-DOSのエディタとか、 いまどき(死ぬまで)使ってるのだし。serow版のsedも、あのログファイルに鳴きを 入れてました。 「思わず使いたくなっちゃう」という状況にあまり遭遇しないのもラッキーなんで しょうね。 ちがう。15.txt, 16.txt, 17.txtあたりでのVzの反応はけっこう規則的でした。 ピンポイントに「ここから不具合が発現する」と特定はできませんでしたが。 これが書きたかったのです。
まあ、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 ------------- これで、1行目のみのファイル(01.org)、1行目と2行目のファイル(02.org) と15個まで作りました。ほんとは20個だったのだけど、19行、20行でawk が鳴きました。--- 20行目あたりに地雷がありそうな感触でもあった。 (sedスクリプトを解説すると、「1q」は、1行目でQuitです。高速です。ただ1行目 は読み込んでからQuit命令=以降ストップ、2行目は読み込みもしない、なので、 1行目だけは出力されます。) 以下は、オリジナルエスキで、0007.cgを挿入したあと。(以前に15個のファイルを 別ディレクトリーにコピーしておいて、>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で差異を外からみる、などしましたが(6個のバッチファイル)、 うーん、もうダメ。 15.txt, 16.txt, 17.txt, 18.txtに対して、0007.cgをどこまで小さくすれば……。 あんまりやる気になってませんねぇ。 このレベルの作業では、VTDOSが鳴くことはなかったと思う。ピカっと光るのは、 今日は未経験。前に書いたかもしれませんが、Vzのステータスバーがリード オンリー時の青に変わって、Vzが固まるのは、16行目、17行目あたりで経験 したと思います。 なんとなく調査範囲を限定したので、割とVzの反応(PCの反応)は、PCらしく 機械的でした。たとえ時にかたまるにせよ。
結果だけ報告します。 16行の被挿入ファイル(0008.cgi)に、80行のファイル(0007.cg)を 挿入すると、結果ファイル(挿入後の大きなファイル)の78、79、80の行で、 行反転が起こります。つまり挿入ファイルの末尾でだけ行反転が起こる。 なぜコピーの最後でだけ起こるのでしょうか? ブロックポインタが最後だけずれるのは、論理的でしょうか? もっとシステマタィックに(規則的に)ずれるだろう、行反転も規則的に起こる だろうと思っていたのです。 いえ、ちょっと驚いただけですなんですが。 この実験は前回に同じく、模範解答と実験結果ファイルのファイルサイズが同一 という、一見挿入成功に見える場合に発生しました。この不具合発現には、再現性が あるように感じてます。 --- 模範解答 --- 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 ---------------- 左端の2ケタ数字はNRというか行番号。 右側の4ケタ数字は論理行長。 経験的に(笑)、2551とかって、決して長すぎるというわけでもないと思う。 1246+2040とかの長さが関係している? あてにはなりませんが、「16行」のファイルを15行、14行と減らしていくと 不具合は出ず、逆に17行、18行と増やしていくと、やがて行反転どころかVzが あるいはVTDOSが飛ぶ、ということになるように感じています。含まれる行の長さ も関係してるのかなぁ。 熱中症はやがて腰が痛くなります。現在、そのフェーズです。
いちおうここにぶら下げます。 元々、0007.cgiの最小サイズを俺も調べてやる(きっと値は違うだろうけど)と 着手した実験でした。目的は、曖昧に、「最小サイズが決まる」という事実を 確認すること。 前回失敗したので、0007.cgiから頭17行(たしか)をとり、これを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だらだらだらだら。 おお、サイズが同じなのに、相違を出してくる。(つまり飛んでない!) では、どう違うのか調査。 Vzでの比較。違う箇所はいちおう特定できたけど、やだ、このログ、読みづらい、と 別の作戦に変更。awk作戦 --- line_len.awk --- { printf("%d %d\n",NR,(length($0))) } -------------------- これで、上記2つの結果ファイルの行番号と行の長さを出し、これをVzで比較>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 ブロックポインタが1バイトずれるだけで、これだけのカオスって起きるの でしたっけ? 僕の誤解? konnoさんの修正を見たときに、1行だけ反転するのか、 とか空想したのですが……。 窓が飛んだりするのは、別の原因なのかな? Vzの、あるいはVTDOSの。 (僕のVTDOS環境が脆弱なのだろうと想像しています。Vzのステータスバーが リードオンリーの青になり、固まる、というのを今日、経験しました。これ、Vzが 固まっているのだと思う。) ああ、またしても、時間切れ、あるいは力尽きて、目的の場所までたどり着け ませんでした。ほんと、次から次に多重出現。 読んでます。多謝。後日レスします。熱中症になりました。ヘロヘロ。ご自愛 ください。畑仕事には、くれぐれもご注意を。
> 上記の、桁折した場合の異常挿入について、[ESC]Iのマクロにトレースを入れたりして、もうちょっと詳しく見ていきたいと思います。
> ・テンポラリファイルエラー(昔からけっこうある)
> 中途段階のブロックエンドポインタが前の行末にずれることにより,行ブロックの挿入位置が1論理行ずれてしまう現象。
> 本来はこの現象の再現性を確認したいのに,その他のエラーも随時からんできて訳がわからない,調査が進まない,条件が確定しないというジレンマに陥っているわけですね。
> 結局,条件が揃えば発現するという状況は避けられない