一括表示

− 野ざらし言 −

[4700] ファイルの挿入とオプションの値

としき 2022/05/03(Tue) 22:43
http://toshiki.la.coocan.jp/
管理人殿より、新規ツリーを推奨されたゆえ、新たに起こします。
が、今回は短い。

#4698で、全てのオプションを全く指定しない環境というのを作りました。
一応、念のため、その環境で、今までと同様のファイル挿入を行ってみたのですよ。
結果。
正しく挿入される。
行の順番が狂わない。
一体これは何。
いや、ほんと、私としては初めてですよ。
何せ、実家のPC-98ですら挿入順が狂ったわけですから。

今日はもうアルコールが入っているのでこれ以上は何もしませんがね。
ここから、オプションをひとつずつでもないけど順に指定していって、一体何がどうなれば挿入順がおかしくなるのかを追及する、という作業をやってみたくなってしまいました。

そんだけ。

[4701] Re: ファイルの挿入とオプションの値

めざら 2022/05/04(Wed) 06:55
[4700]へのコメント http://mezala.la.coocan.jp/
おそれいります。
> が、今回は短い。
いやいや,せっかくだからこの際とことん突き詰めましょうよ。
めざら環境で出ていない症状なので,お手伝いが難しいのですが……

ただ,メモリ関係…特に EM XM …の値が,あの初期値になるということは,これまた環境によって変化する可能性が大きいのでは?という気がします。

あ。…ということは,その辺りの値をいろいろ変更してみると,うちの環境でも発生する可能性があるのかな……

[4702] Bl の値が関係しているかも

konno 2022/05/04(Wed) 19:06
[4700]へのコメント
> #4698で、全てのオプションを全く指定しない環境というのを作りました。
> 一応、念のため、その環境で、今までと同様のファイル挿入を行ってみたのですよ。
> 結果。
> 正しく挿入される。
> 行の順番が狂わない。
> 一体これは何。

これを見て色々試してみた結果、分かったかもです。

私の環境で、Bl1024 に変更したら、正常に処理されました。
VTDOS では駄目ですが、NTVDM などその他の環境で正常になるようです。
Bl の値を色々変えてみました。

としきさんのデータでは
Bl1024 〜 Bl1024*5 の範囲で正常処理できました。

私のデータでは、長い行があるためか
Bl1024*4 〜 Bl8190 または Bl1024*7 位まで正常処理されました。

両方の環境で使える値は
Bl1024*4 〜 Bl1024*5 位の範囲となりますね。
理由は不明です。

[4703] Re: Bl の値が関係しているかも

としき 2022/05/05(Thu) 00:52
[4702]へのコメント http://toshiki.la.coocan.jp/
konnoさん、いろいろと追試していただきありがとうございます。
私のところでも同じような結果となりました。常用環境からBlのみ1024に変更して、異常挿入が発生しないことを確認しました。
ただ、めざらさんのところではBl8192で異常挿入が発生していないんですよね。
ということは、まだ何か関係する部分があるのでしょうね。

> 私のデータでは、長い行があるためか

ごめんなさい。
konnoさんのおっしゃる「私のデータ」というのがよくわかりません。
何番の発言で言及されているものでしょうか。

[4704] Re^2: Bl の値が関係しているかも

konno 2022/05/05(Thu) 01:46
[4703]へのコメント
> ただ、めざらさんのところではBl8192で異常挿入が発生していないんですよね。
> ということは、まだ何か関係する部分があるのでしょうね。

これ、私も疑問に思い、ログを確認したら、Bl8192 だったんですよね。
この数値で正常になる環境がわかれば、バグの箇所特定に繋がりそうですが。

> konnoさんのおっしゃる「私のデータ」というのがよくわかりません。
> 何番の発言で言及されているものでしょうか。

#4667 で書いている 381k のデータのことです。
としきさんのデータをもらう前は、私の手持ちのデータで検証していました。

[4705] Re^3: Bl の値が関係しているかも

としき 2022/05/05(Thu) 12:59
[4704]へのコメント http://toshiki.la.coocan.jp/
あのあと、うちの環境では、オプション全て初期値(行頭セミコロン状態)からBlのみ8192を指定したWinXPのcommand.comで挿入異常が発生することを確認しました。

> #4667 で書いている 381k のデータのことです。

ありがとうございます、見つけました。
これって、どっから引っ張ってきたデータというか、どんなものなんですか?
行数とか、一番長い行の長さとか。
ちなみに、私の提供したデータのほうは、一番長い行は、*.cgiのほうは3700バイトあまり、*.cgのほうは2700バイトあまり。でも、どっちにどっちを挿入しても挿入異常は発生する。なので、次に私が試そうとしているのは、全ての行を例えば2048バイト未満にする、それでだめなら次は1024バイトだ、みたいなことです。

[4706] Re^4: Bl の値が関係しているかも

としき 2022/05/05(Thu) 14:39
[4705]へのコメント http://toshiki.la.coocan.jp/
他にやりたいことはいっぱいあるのに、こっちが気になって仕方ない。
ということで、#4609からのツリーを読み直しています。

まず、自分の発言#4630で、製品版.defだと異常挿入が発生しないと報告しました。そこで製品版.defをみると、Bl2048になっているのですね。納得しました。
次、konnoさんから#4667でBtの値を変えると状況が変わるという報告があがっています。これについて、実は私、まだ実験をしていないので、のちほど再現実験を行います。ただ、これに関連して、めざらさんが#4651

>  ※BlはBtの指定サイズの128倍の値であること

と書いているのですが、これってどういうことなんでしょうか。
これについての追加の情報提供をお願いいたします。

続いて、めざらさんの#4663で、不具合は表示だけではないか、という疑問の表明がありました。この件に関して、私、しっかりレスポンスを返していなかったようなので、ここで明確にしておきますが、異常挿入が発生したところでそのままファイルを保存すると、見た目どおりというか、間違いなく異常な行の並びになったファイルが保存されてしまっているので、表示だけがおかしい、ということではありません。

ということで、次に試すのは、テキストファイルのぶつ切りの前に、Btの値の変更実験かな。
ただ、それは今夜。
とりあえず、頭をスッキリさせるために軽くゲームしたら、一旦パソコンの電源を落として3時のお茶。それから各種家事、といったところですね。

[4707] Re^5: Bl の値が関係しているかも

としき 2022/05/05(Thu) 17:46
[4706]へのコメント http://toshiki.la.coocan.jp/
> 次に試すのは、テキストファイルのぶつ切りの前に、Btの値の変更実験

試してみました。
いつもと同じくWinXPのcommand.com、Vztです。
常用環境からオプションの行頭を全てセミコロンで潰し、Bl8192だけ生かしたところ異常挿入発生を確認、というのは先にあげましたよね。
ここで次に、Bt64を生かしても異常挿入が継続。
さらにBt62にしたら正常に挿入。一応、念のため、Bl8192でBt63というのも試してみましたが、これでも正常に挿入。

何気に危険な雰囲気がぷんぷん漂う設定値ですが、とりあえずご報告ということで。

[4708] Re^5: Bl の値が関係しているかも

めざら 2022/05/06(Fri) 18:23
[4706]へのコメント http://mezala.la.coocan.jp/
>  ※BlはBtの指定サイズの128倍の値であること

マニュアルの記載に基づくものです。「基づく」というのは,このまま書いてあるわけではなく,p178のBlの項に「[範囲] 1024 〜 Bt*1024/8」とあります。
これはBlの最大値が,Btの最大値64*1024/8 == 8192 であることを示します。

指定範囲の最大値に基づくものなので,Btが最大値でない場合は不正確な記述であるのかもしれませんし,そうでないと不具合があるのかもしれません。ただ,無指定時に Bt==64 で Bl==1024 になっているということなので,早とちりなのかな。

なお,不具合が「実害」であることも了解しました。
こちらでもオプションの値を変更してみて,症状が出るのか確認してみます。

当面,アレコレ時間が取れないので,結果がいつになるかわかりませんが……

[4709] Re^6: Bl の値が関係しているかも

としき 2022/05/07(Sat) 12:08
[4708]へのコメント http://toshiki.la.coocan.jp/
BtとBlの関係については理解しました。
ということはつまり、Btを減らしたらBlも減らす必要がある、という気がしてくるわけですが、確かに無指定時の値から考えると不思議。
何がどうなっているやら。

> こちらでもオプションの値を変更してみて,症状が出るのか確認

お時間のあるときで結構です。
ただ、その際に、ひとつだけ試していただきたいことがあって。
なにかというと、製品版.defファイル、つまりVZIBMJ.DEFでの実験。
私のところだと、前にも書きましたが、1.60t03kに製品版.defファイルを持ってきても異常挿入は発生しません。そこで今回、改めて確認したところ、この.defファイルで他のものを一切変えず、Blだけを8192にすると異常挿入が発生しました。
ということで、ここがもしかしたら出発点のひとつになるかもしれません。
全く状況が発生しないめざらさんのところなので、この実験でも異常挿入は発生しなさそうな気がしますが、数週間後でも構いませんので、ぜひ結果を教えてください。

[4710] Re^7: Bl の値が関係しているかも

めざら 2022/05/07(Sat) 16:34
[4709]へのコメント http://mezala.la.coocan.jp/
> ということで、ここがもしかしたら出発点のひとつになるかもしれません。

なるほど,原点回帰は重要な手法です。

農繁期に天気のよい日が続いたので,しばらく頑張って作業を連日やっていたのですが,どうやら頑張りすぎたらしく,疲労が蓄積してしまいましたから当面はゆるゆるやろうと思います。そしたら時間もとれるでしょう。

[4727] Re^4: Bl の値が関係しているかも

としき 2022/05/22(Sun) 15:13
[4705]へのコメント http://toshiki.la.coocan.jp/
まずは謝罪と訂正。
ごめんなさい。

> 私の提供したデータのほうは、一番長い行は、*.cgiのほうは3700バイトあまり、*.cgのほうは2700バイトあまり。

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

*.cgiのほうは 6600 バイトあまり
*.cgのほうは 5000 バイトあまり

ということでした。
大変申し訳ありません。

で、まぁ、行の分割というところに手をつけようとしているのですが。
最終的にはawkを使って機械的に分割することになると思います。
その前に、手作業で、0007.cgiの長いほうから3つの行を分割しました。
これにより、このファイルで一番長い行は4200バイト程度。
このファイルで常用環境で実験した結果、挿入異常発生。

と、ここまで実験したところで、実家から緊急コール。
CATVのチューナーに異常発生、とのこと。
リモコンではなくチューナー本体の電源ボタンを押しても電源が切れない、というくらいなので、これはちょっとおおごとっぽい。
実家に行くといつ帰れるかわからないので、とりあえず洗濯物と布団を取り込んで、それから訪問修理。
今夜、続きはできるかなぁ。

[4728] Re^5: Bl の値が関係しているかも

としき 2022/05/22(Sun) 19:24
[4727]へのコメント http://toshiki.la.coocan.jp/
> 今夜、続きはできるかなぁ。

実家の問題はあっという間に回復。電源ケーブルの抜き差しリセット、だけ。

> で、まぁ、行の分割というところに手をつけようとしているのですが。
> 最終的にはawkを使って機械的に分割することになると思います。

ある程度以上長い行を単純に2分割するスクリプトを作りました。
インデントは省略。

BEGIN{
divlen=2048
}
{
if (length($0)>divlen) {
print substr($0,1,int(length($0)/2))
print substr($0,int(length($0)/2)+1)
} else print $0
}

そして、これに0007.cgiをかけて0008.cgiを作りました。
0008.cgiで一番長い行のバイト数は3346バイト。
一応、gawkとjgawkの両方で試しましたが、jgawkだと2バイト文字の片割れが発生してしまう。gawkは大丈夫。jgawkの場合はjsubstrを使う必要があります。

常用環境で、この0008.cgiを開いて、ファイル先頭でいきなり0007.cgを挿入したところ、正常挿入。
一方、0007.cgを開いて0008.cgiを挿入すると、異常挿入。

この結果より、これから挿入しようとするファイルではなく、現在開いているファイルのほうの最大行長に依存する不具合である、といってよろしいかと。
あと、実際、このスクリプトで分割された行数は、高々11行ばかり。
これくらいなら、手作業でも何とかなりそう。
なので、ここから先、手作業で追い込んでいこうかな。
あと、0007.cgiだけではなく、0007.cgファイルのほうにも手を加えて、閾値というか限界値の範囲の追い込みができるとうれしい。
とりあえず次の目標は4096バイトあたりで切断、かな。

[4736] Re^6: 何が関係しているのやら

としき 2022/05/30(Mon) 01:03
[4728]へのコメント http://toshiki.la.coocan.jp/
> なので、ここから先、手作業で追い込んでいこうかな。

手作業で追い込んでみました。
結果。
0007.cgiの15行目くらい、「2632」で始まる行があるかと思います。
1行がおおむね4023バイトくらい。
この行を約2000バイトくらいで2分割し、他の行は全く手を加えていない状態のファイルを作り、一旦閉じて開きなおしてから0007.cgを挿入したところ、正常挿入。なんと。
ファイル先頭から、この15行目の行末までのテキストのサイズは29685バイトくらい。分割した場合は約2000バイト少なくなるわけで、27651バイトほど。


うむ、大体追い込めたような気がする。
ということで、今後の予定。
該当の行を、約2000バイトずつ2分割、ではなく、1000バイトと3000バイト、みたいな感じで分割サイズを変えて、どの辺に境界があるのかを探ってみたいと思います。

[4738] Re^7: 何が関係しているのやら

めざら 2022/05/30(Mon) 07:50
[4736]へのコメント http://mezala.la.coocan.jp/
被挿入ファイル(cgi)の長い行を分割すると,正常に挿入されるということですか?

行が入れ替わるのは挿入ファイル(cg)の方ですよね……一体,どういうことなのだろう。

そりゃ,挿入するということはメモリ上で全部ずらしていくわけだから,ずらしの途中で何かにつっかえる場合があるのかもしれないけれど,問題の(少なくとも現象としては)#Bの挙動との関連に繋がらないですね。

[4740] Re^8: 何が関係しているのやら

としき 2022/05/31(Tue) 10:50
[4738]へのコメント http://toshiki.la.coocan.jp/
> 被挿入ファイル(cgi)の長い行を分割すると,正常に挿入されるということですか?

そのとおりです。
全くもって直感に反した挙動、といったところでしょうか。
なので、今後の予定としては、#4736にも書いたとおり、.cgiファイルのたった1ヶ所の行分割の分割位置を変更してみる、ということのほか、#4728のスクリプトを.cgファイルのほうに施したファイルを作って実験してみるつもりです。

あと、#4736に書いたように、たった1ヶ所、改行を挿入するだけのことですので、できればめざらさんにもエラーの出方が変わるか追試していただけるとありがたいです。もし仮にエラーの出方が変わるというのであれば、これは同じ病気の違う症状といっていいかもしれません。とはいえ、ここまで挙動が違うのはそれだけ環境が違うわけで、エラーの出方は変わらないような気もしますが。

[4768] Re^7: 何が関係しているのやら

としき 2022/06/13(Mon) 17:37
[4736]へのコメント http://toshiki.la.coocan.jp/
> 分割サイズを変えて、どの辺に境界があるのかを探ってみたいと

やっと、試してみました。
結果。
前にも書きました15行目、「2632」から始まる行を、前半が2239バイト、後半が1784バイトに分けたとき、正常に挿入されました。一方で、同じ行を、前半が2319バイト、後半が1704バイトに分けたときには異常挿入。
この、正常挿入されたファイルの前半部分の行頭から分割位置までのテキストの総量は27901バイト、分割位置からファイル末尾までのテキストの総量は14236バイト。
異常挿入されるファイル分割の場合は、それぞれ80バイト違うわけですから、前半は27981バイト、後半は14156バイト。

うむ、なんとなく、前半のファイルサイズが32キロバイトに近いところがプンプンにおう。
ということで、次の実験。
上記の、異常挿入となった、27981+14156のところの改行を入れたファイル、これを0010.cgiとでもしましょうか。こいつの一番尻尾の1行、行頭が「2735」で始まる行を1行丸まる削除してみました。これを一旦保存して、再度開いてファイル先頭で0007.cgを挿入すると、そのまま異常挿入。
一方で、この0010.cgiのファイル先頭の「2515」で始まる行を丸々1行削除して保存、そして開きなおして上記と同様にファイル先頭で0007.cgを挿入すると、正常挿入になりました。念のため、「2515」で始まる行ではなく、論理行2行目の「2534」で始まる行を削除しても同様に、正常挿入となりました。

ということで、例えば、ですが、ファイル先頭に挿入するときで言えば、既に開いているファイルの先頭部と挿入しようとするファイルをブロックで扱ったときの合計サイズが、Blか何かで指定される何らかのバッファなりテンポラリファイルの処理でこけてしまっているのではないか、と想定しました。

[4780] Re^8: 何が関係しているのやら

としき 2022/06/15(Wed) 15:14
[4768]へのコメント http://toshiki.la.coocan.jp/
どっちのツリーに書こうか迷ったのですが、こちらにつけます。
実は私、1.60製品版のVZIBMJでの結果は#4711から始まるツリーに書いていました。一方、こちらの#4700から始まるツリーに書いているものは全て、私の常用環境、すなわち高橋版での結果です。

さて

> こいつの一番尻尾の1行、行頭が「2735」で始まる行を1行丸まる削除
(中略)
> ファイル先頭で0007.cgを挿入すると、そのまま異常挿入。

このような結果になったことから、常用環境で、どこまで尻尾を切れるか試してみたのですよ。するとなんと、手作業で改行を入れたところまでのファイル、すなわち行数15行、ファイルサイズ27981バイトのファイルを開いた状態でファイル先頭に0007.cgを挿入すると異常挿入。
そして、同じ動作をcommand.comから1.60製品版の実行ファイルと.defファイルを使って行うと、正常挿入となりました。一方で、Bl8192に変更した.defファイルだと、製品版でも異常挿入となりました。


一応、今後の予定。
異常挿入を起こす最小の.cgiファイルは発見できました。
次は、もともとの0007.cgiに対して、異常挿入を起こす最小の.cgファイルというものを追及したいと思います。
そして、それぞれのファイルサイズの組み合わせから、何かを発見できればうれしいかな、と。

[4746] Re^6: Bl の値が関係しているかも

としき 2022/06/06(Mon) 11:50
[4728]へのコメント http://toshiki.la.coocan.jp/
#4740に書いたように

> #4728のスクリプトを.cgファイルのほうに施したファイルを作って実験

してみました。

> そして、これに0007.cgiをかけて0008.cgiを作りました。
> 0008.cgiで一番長い行のバイト数は3346バイト。

このスクリプトに0007.cgをかけて0008.cgを作りました。
0007.cgで一番長い行は5035バイト、0008.cgで一番長い行は3605バイト。
この0008.cgを開いておいてファイル先頭に挿入しようとした場合、0007.cgiだろうが0008.cgiだろうが、異常挿入となりました。
ここでちょっと極限値というか、foldコマンドを使って72桁で桁折した0007fold.cgというファイルを作り、このファイルを開いた状況でファイル先頭に挿入しようとすると0007.cgiだろうが0008.cgiだろうが正常挿入。
今のところ、この方向はこれ以上追及するつもりはありません。
そもそもイレギュラーだったわけだし。


ということで、今日は時間切れ。
#4736に書いた分割位置を変えるというのは必然的に手作業にならざるを得ないので、早くて明日、もしかしたらあさって以降になってしまうかな。

[4747] Re^7: Bl の値が関係しているかも

としき 2022/06/07(Tue) 23:45
[4746]へのコメント http://toshiki.la.coocan.jp/
> 今のところ、この方向はこれ以上追及するつもりはありません。
> そもそもイレギュラーだったわけだし。

そのつもりだったのですが、一応、網羅的に、ということで。
試したファイルは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窓を開いてすぐのとき
のみ、ということ。いろいろと作業ををしていて、ふと思い立ってファイルの
挿入を試すと、上記で正常となっているところも異常だったことがあります。
これはおそらく、コンソールファイルか何かわかりませんが、何かのファイルの
テンポラリファイルへの移動が関係するとかメモリ使用状況が違うとかがあった
ためだと思われます。
 

[4748] Re^8: Bl の値が関係しているかも

めざら 2022/06/08(Wed) 10:47
[4747]へのコメント http://mezala.la.coocan.jp/
テストお疲れ様でした。
0007.cgiに0007fold.cgを挿入したケースだけ異なるパターンですね。

ある程度環境を揃えてそれなりの成果はあるような気はしますが,やはり #B に結構レアなバグがあるのではないか…という想像をするところまでですね。

ペースト後カーソル位置更新オプション ek も同様なバグがあるとすれば,共通したルーチンが呼ばれているか,ロングポインタのアドレス計算に不備があるのか…というところなのでしょう。

ソースで追うのは難しそうだなぁ。
榊原さんや高橋さんですら見過ごしたところなのですよね。

blサイズを超える長い論理行と,テキストスタックに収まりきらない巨大ブロック転送処理における,ちょっとした歯車の外れ加減……

パーフォレーションの破損でスクリーンが流れるわかり易さと違うなぁ……

[4749] Re^9: 何かの値が関係している・・・

としき 2022/06/08(Wed) 18:22
[4748]へのコメント http://toshiki.la.coocan.jp/
いろいろ試していたのですが、バグがあるのは#Bではなくテンポラリファイルの処理ではないか、という気がしてきました。
具体的には、0007.cgiと0009.cgiの2つのファイルを開き\[F03]でファイルの比較をする場合に発生したことです。縦分割、または横分割画面では1回も発生しませんが、どちらか片方のファイルだけを表に出してファイル先頭から比較をし、相違があると停止したところで裏に回っていたファイルを表に出すと、裏と表で全く異なった場所を表示している。
ただ、この挙動も、常に起こるわけではなくて。
しかもその上、挙動はおかしいくせに、テンポラリファイルエラーとかの表示は出てくれない。
ん〜、根本原因は、テンポラリファイルエラーが起きているのにもかかわらず、そうと表示してくれないこと、なのかも知れない。

私、テンポラリファイル関係の処理とか過去のバグ報告には全く詳しくないのですが、ここまでの挙動からの直感でものを言うと、テンポラリファイル処理ってある一定の単位で行っているのだと思います。ところがその際に、その処理単位と処理すべき行の論理行長の関係で、Vzの側で検知できないエラーが発生しているのではないか、と。
そして、上記に言うところの「一定の単位」というのが、Blなり他の変数によって可変、ということなのではないかなぁ。
ま、この辺、完全に私の妄想かもしれませんけどね。

[4750] Re^10: 何かの値が関係している・・・

めざら 2022/06/08(Wed) 20:36
[4749]へのコメント http://mezala.la.coocan.jp/
画面分割せずにテキスト比較って,かつて一度もやったことないですね。
そういう操作って,想像もしませんでした。
確かに分割必須ではないですけど……,なんか不便じゃないですか?
まぁ,それは好みなので,どうでもよいことなのですが,もしかするとサイレントの処理にかかわることではあるまいかと思いました。ただの想像ですが。

[4751] テキスト比較

としき 2022/06/08(Wed) 23:08
[4750]へのコメント http://toshiki.la.coocan.jp/
今日は既にアルコールが入っているので、わき道にそれさせていただきます。

私、テキスト比較って、8割か9割か、結構高い確率で、画面分割せずに行っています。そして、[F02]で窓換、というパターン。
なぜそうなのかというのは、自分の心の中なのに、もしくは、自分の心の中だからこそ、はっきりした事は分かりませんが、おそらく、画面に表示される情報量が多いことを好むからではないか、という気がしています。

そんだけ。
#あぁ、酔っている

[4754] Re: テキスト比較

めざら 2022/06/09(Thu) 20:11
[4751]へのコメント http://mezala.la.coocan.jp/
そんなとしき兄に,榊原さんの「一目で比較」.

========== 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)                   ;簡易テキスト比較にも使える

[4765] Re^2: テキスト比較

としき 2022/06/13(Mon) 01:37
[4754]へのコメント http://toshiki.la.coocan.jp/
> ========== HIKAKU.DEF ==========

あはは、これ、いいですね。
常用するかは別にして、こういうアイディアは大好きです。

> あるいは,m.gann師のマクロ連続実行.

こっちはよくわからない。
単に画面を入れ替えているだけ、のような気がします。
既存の[F02]連打と、何が違うのでしょうか?

[4769] Re^3: テキスト比較

めざら 2022/06/13(Mon) 23:20
[4765]へのコメント http://mezala.la.coocan.jp/
> 既存の[F02]連打と、何が違うのでしょうか?

分割画面にすると分かりやすいと思いますが,
[F02]は分割画面を相互に行き来するだけになるので,
見た目比較ができません。

…と言うか,見た目比較が目的のマクロではないので,本来は
目線をブレさせない状態(分割した一方の画面を編集画面に固定)で
ふたつのファイルを交互に編集したいということなのでしょう。(想像)

そこで,画面の分割に応じた入れ替えを行っているわけです。

例えば,二画面ファイラーで,常に左をコピー元,右をコピー先という
配置にこだわりたい人(それは自分)の感覚に似ているかもしれません。
ん? 話がずれた?

[4779] Re^4: テキスト比較

としき 2022/06/15(Wed) 01:14
[4769]へのコメント http://toshiki.la.coocan.jp/
> 分割画面にすると分かりやすいと思いますが,

わかりました。わかりやすいです。
なるほど、入れ替えているのですね。
分割画面で比較することが少ない私には、HIKAKU.DEFのほうが向いているような気がします。

> 例えば,二画面ファイラーで,常に左をコピー元,右をコピー先という
> 配置にこだわりたい人(それは自分)の感覚に似ているかもしれません。

この感覚は、逆の意味でわかるような気がする。
逆というか、私は左右でコピー先とコピー元にこだわらない人なんですよ。
でも、時々思うのが、こだわらなさ過ぎていいかげんだなぁ、という気持ち。
なので、そのこだわりは重要かもしれません。

[4753] Re^9: Bl の値が関係しているかも

konno 2022/06/09(Thu) 01:14
[4748]へのコメント
> ペースト後カーソル位置更新オプション ek も同様なバグがあるとすれば,共通したルーチンが呼ばれているか,ロングポインタのアドレス計算に不備があるのか…というところなのでしょう。

私も同じように思いました。
&t トレースでは ek-, の時 #i の挿入でカーソル位置がズレたように見えたので。

> ソースで追うのは難しそうだなぁ。
> 榊原さんや高橋さんですら見過ごしたところなのですよね。

今の私では全く分からないですね。先人との格の違いを思い知らされます。

[4802] Re^6: Bl の値が関係しているかも

としき 2022/06/20(Mon) 14:08
[4728]へのコメント http://toshiki.la.coocan.jp/
ここまで戻ります。

> ある程度以上長い行を単純に2分割するスクリプトを作りました。
> そして、これに0007.cgiをかけて0008.cgiを作りました。

このスクリプトに0007.cgをかけて0008.cgを作りました。
そして、0007.cgiを開いておいて0008.cgを挿入。結果、異常挿入。
この0008.cg、gawkを使って作ったので、行長判定は文字数となります。
そこで、バイト数で行長判定を行うmawk32を使って0008m.cgというのも作ってみましたが、やっぱり異常挿入。
このスクリプトでは長い行を単純に2分割しているだけですので、一定長で桁折しようと、次に、foldを使って2048バイトで桁折しました。が、これでも異常挿入。
では、どこまで桁折を短くすれば正常挿入になるかとどんどん短くしていったのですがね。なんと、桁折1桁、すなわち全角だろうが半角だろうが1文字単位で改行したファイルであっても異常挿入。


結論。
この事象は、あとから挿入しようとするファイルの行長には依存しません。
既にオープンしているファイルにのみ依存する事象です。

ということで、追及の方向は定まりました。
今後は、#4768に書いた0010.cgiにいろいろと手を加えて、どういうときに異常挿入になってどういうときは正常化、というところを探っていきたいと思います。
一応、念のため再掲。
0010.cgiは0007.cgiの先頭15行目の途中に改行を入れて、そこから後ろを全部削除した27981バイトのファイルです。
ただ、ここからどういう風に追及すればよいか、今の所は考えがまとまっていません。方向とか内容によっては新ツリーにしますが、一方で、それらの内容によっては、こちらかあちらの既存ツリーにつけます。

[4805] Re^7: Bl の値が関係しているかも

konno 2022/06/21(Tue) 00:10
[4802]へのコメント
> 結論。
> この事象は、あとから挿入しようとするファイルの行長には依存しません。
> 既にオープンしているファイルにのみ依存する事象です。

おお、言われてみれば、納得です。
ブロック移動が5回くらい行われるので、170k / 5 = 34 1回あたり約34kづつかな。
3回目くらいからズレてくるので、結局64k超のファイルを後ろに移動させているのですよね。

私の考えでは、64k超で、1行が長くて、漢字交じり(文字化けとズレの要因?)
が条件かと思っています。

[4806] Re^8: Bl の値が関係しているかも

としき 2022/06/21(Tue) 01:36
[4805]へのコメント http://toshiki.la.coocan.jp/
> 私の考えでは、64k超で、1行が長くて、漢字交じり(文字化けとズレの要因?)
> が条件かと思っています。

この部分は、もしかしたら環境に依存するかもしれません。
#4802にも書いたとおり、私の常用環境ではたかだか28Kバイトにも満たないファイルで異常挿入が発生するのですから。
konnoさんのところでは発生しないのかもしれません。
例えば、0007.cgiを開いてファイル先頭でブロックモード、^QJで17行目にジャンプしてそこで[ESC]Sとやって0008.cgiとかっていう新しいファイルを作ったとして、そのファイルを開きなおして異常挿入は発生するかしないか。
これを追試していただけるとはなはだ幸甚に存じます。

[4809] Re^9: Bl の値が関係しているかも

konno 2022/06/22(Wed) 01:51
[4806]へのコメント
> 例えば、0007.cgiを開いてファイル先頭でブロックモード、^QJで17行目にジャンプしてそこで[ESC]Sとやって0008.cgiとかっていう新しいファイルを作ったとして、そのファイルを開きなおして異常挿入は発生するかしないか。
> これを追試していただけるとはなはだ幸甚に存じます。

うう、0008.cgi を作って、その先頭に 0007.cg を挿入すると異常になりますね。
0008.cgi のサイズは

2022/06/22 00:46 31,369 0008.cgi

32k も無いのに不具合が出るとは、奥が深いですね。

[4813] Re^10: Bl の値が関係しているかも

としき 2022/06/22(Wed) 16:14
[4809]へのコメント http://toshiki.la.coocan.jp/
> 32k も無いのに不具合が出るとは、奥が深いですね。

そうなんですよ。
もう深すぎて、ずぶずぶ沈んでいくだけ。
また、こんな小さなファイルでも、めざらさんのところでテンポラリファイルエラーが生じるかという点も気になるところのひとつです。

[4822] Re^11: Bl の値が関係しているかも

文太 2022/06/24(Fri) 00:28
[4813]へのコメント
飛ばない論理行長

--- 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」の2行を削れば飛びませんでした。
 3703 bytes の論理行は耐えるようなので、僕の 2560 bytes より、けっこう
長いみたいですね。もっとも他にも実は入っている要因とかもあるのかもですね。
 Bl8192, Bt64 の環境です。

[4827] Re^12: Bl の値が関係しているかも

としき 2022/06/24(Fri) 12:19
[4822]へのコメント http://toshiki.la.coocan.jp/
> 飛ばない論理行長

これについては、うちの環境だと、#4736に書きましたが、0007.cgiの15行目を分割すると、他の長い行を全く削除せずに正常挿入になりました。
0008.cgiと違って0007.cgiは100行以上あって、論理行長がもっと長い行もあると思いますが、それでもこういう結果なので、現状、私はテンポラリファイルを疑っているのですよ。

[4829] Re^13: Bl の値が関係しているかも

文太 2022/06/24(Fri) 16:47
[4827]へのコメント
 「全角→半角。闇&病み」の事実から、テンポラリーファイルも絡んでいるのは有力な仮説でしょうね。

[4865] AWKのヴァージョン

文太 2022/07/06(Wed) 00:06
[4727]へのコメント
 こんな長い行を扱うことになるとは……。
 そして日本語化はどうなってたっけ? というわけで、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
----------------------------------------------------------------------

[4869] Re: AWKのヴァージョン

としき 2022/07/07(Thu) 19:27
[4865]へのコメント http://toshiki.la.coocan.jp/
私が使っているawkは3種類。


C:\>jgawk -W version
Japanized Gnu Awk (jgawk) 2.15.2 + 1.1(SJIS)


C:\>gawk -W version
GNU Awk 3.1.5 build date Feb 10 2006
Copyright (C) 1989, 1991-2005 Free Software Foundation.


C:\>mawk32 -W version
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan
Microsoft C/C++ _MSC_VER 1100
Adaptation for MBCS (P. yedoensis R27) by KIMURA Koichi
compiled limits:

max NF 32767
sprintf buffer 1020


> C:\>mawk -W version

こいつだけ私、違うバージョンを使っていますね。
一応、32ビットバージョンだと思う。
2バイト文字の扱いその他は16ビットバージョンと同じはずです。

[4875] Re^2: AWKのヴァージョン

文太 2022/07/10(Sun) 14:38
[4869]へのコメント
 やっと整理ができた。たんにコレクターなだけです。でも思うに、
これらの(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

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

[4783] 実験は試みたけど

文太 2022/06/18(Sat) 21:03
[4700]へのコメント
 当然、異常発生はなし。

 ここに貼ってよいですか? 標準defではないです。僕の常用環境。

【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

(注)ふつうの本の1段落が1000字程度ということ。1論理行が 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)では
挙動はきっと同じでしょう。

[4784] Re: 実験は試みたけど

konno 2022/06/18(Sat) 22:55
[4783]へのコメント
>  ここに貼ってよいですか? 標準defではないです。僕の常用環境。

文太さん、[ESC]I の実験に協力していただきありがとうございます。

やはりテストデータはとしきさんのものを共有して同じ実験環境にしたいですね。
ということで、勝手ながら、としきさんのテストデータをメールで送りました。
このデータはみんなで共有しているので同じ実験環境になると思います。
としきさんからクレームが出たら削除願います。>としきさん、ごめんなさいね。

添付ファイルは

2022/03/03 01:00 170,335 0007.cgi オープンするファイル
2022/03/02 23:04 132,553 0007.cg [ESC]I で挿入するファイル
2022/03/03 19:11 302,888 0007-i.cgi 正常な結果ファイル(比較用)

よろしくお願いいたします。


環境としては、 Bl8192 なら NG になると思います。

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

これは製品版の [ESC]I でしょうか? 製品版のマクロでないと結果が違うかもです。

> 1994/03/01 14:26 1,653 NAGASA.DEF ;by syoさん
> 1994/03/01 12:59 1,111 NAGASA.DOC ;最長行測定に使用。

おお、これいいですね! 

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

私もそう予想しています。

[4786] Re^2: 実験は試みたけど

文太 2022/06/18(Sat) 23:20
[4784]へのコメント
konnoさん

>環境としては、 Bl8192 なら NG になると思います。
 NGというのは、不具合発現ということでしょうか? 発現しないんですが。
 発現させるのが、やたら大変なバグ(?)なんでしょ?

>> 使用マクロ:"
>> 8 [ESC]I "Insfile" &88"
>これは製品版の [ESC]I でしょうか? 製品版のマクロでないと結果が違うかもです。

 前に話題に出ていたと思った以下です。有名ですよ。

======== insfile.def ======== by I.kamimura
#if 0
【カーソル位置へ挿入】

 そんなに一生懸命、バグを発現させたいとは思っておりませんで……。
 そんなに出ないなら、いいじゃん、みたく。

[4789] Re^3: 実験は試みたけど

konno 2022/06/19(Sun) 00:19
[4786]へのコメント
>  NGというのは、不具合発現ということでしょうか? 発現しないんですが。
>  発現させるのが、やたら大変なバグ(?)なんでしょ?

VZのオプション条件を同じにすれば同じように出ているので再現はできます。
Ek- でないと出ない、という条件を忘れていました。

> ======== insfile.def ======== by I.kamimura

このマクロはバグが出ないマクロのようです。

#4653 insfile.def 正常に動作します
#4654 insfile.def を見てみると、ループ中に #B を使っていません。

>  そんなに一生懸命、バグを発現させたいとは思っておりませんで……。
>  そんなに出ないなら、いいじゃん、みたく。

すみませんね、今となっては興味本位かもしれませんが、気になるので。

[4785] 0007.cgiとか(追試)

文太 2022/06/18(Sat) 23:14
[4783]へのコメント
 結果。異常は見られず。

【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.

[4787] オリジナル・エスキ(追試2)

文太 2022/06/18(Sat) 23:41
[4785]へのコメント
------------------------------------------------------
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.

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

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

[4790] Re: オリジナル・エスキ(追試2)

konno 2022/06/19(Sun) 00:24
[4787]へのコメント
>  どうやら、僕のVz環境は最強みたいです。でません。別にでてもらわなくて
> 構いませんが。

すみません、オプションの条件を書き忘れていました。
Ek- でないと出ない、という条件を忘れていました。

Ek- で、Bl8192 の条件でオリジナルの [ESC]I が正常なら、凄いです。
もしかしたら、16ビット環境では問題無い、ということになるかもです。

[4791] Ek-(追試3)

文太 2022/06/19(Sun) 01:07
[4790]へのコメント

 オリジナル・エスキ + Ek- の条件で、再現はしましたが……。


【WinME】
vz.def
;Ek+  ;ブロックペースト後カーソル位置更新
Ek-   ;ブロックペースト後カーソル位置更新

C:\>diff e:\ww\0007.cgi e:\ww\0007-i.cgi
536a537,546
> 2599<>2577<>1<>aa: 水耕栽培<>aaaaaaa@aaaa.aaa.aa.aa<>aaaa://aaaaaaaa3.aaaaa.aaa/~aaaaaaa/<>としき@家主<>9996/05/17 15:16<>&aa; 一つは、ザルの上で作物を育て、根はザルの下に伸ばす方法。昔、私が小学生か<aa>&aa; 中学生のころ、この方法でカイワレ大根なんかを作 ※【ここに化け文字があった】


【Win7】
I:\WW>diff 0007.cgi 0007-i.cgi
77a78
> 2599<>2577<>1<>aa: 水耕栽培<>aaaaaaa@aaaa.aaa.aa.aa<>aaaa://aaaaaaaa3.aaaaa.aaa/~aaaaaaa/<>としき@家主<>9996/05/17 15:16<>&aa; 一つは、ザルの上で作物を育て、根はザルの下に伸ばす方法。昔、私が小学生か<aa>&aa; 中学生のころ、この方法でカイワレ大根なんかを作 ※【化けてない!】る容器を親が買ってきました。<aa>&aa; 今では使っておりませんが、


 深そうですね。「文太さんの WinME環境 と Win7環境では何が違うんですか?」と訊かれても、そりゃ、やっぱり色々違いますよ、と思ったのですが、

#if ME VT
"ファイル","窓換","文換","窓割","窓動","DDWn","FOPN","tagJ","Gtag","dDOS","EXIT","STKH"

#elseif XP

#elseif DOSS

#endif

 いや、それほど違わないのかもしれない、Vz的には。

[4795] Re: Ek-(追試3)

としき 2022/06/19(Sun) 15:20
[4791]へのコメント http://toshiki.la.coocan.jp/
この問題に、ついに文太さんまで巻き込んでしまいましたね。

ところで、私自身はあまり文字化けには出会っていないんですよ。
全く出会っていない、というほどでもないのですが、再現条件をほとんど絞り込んでいません。
一方で、それよりも頻度が高いのが、ジャンプとかテキスト比較の場合に、カーソル位置が全く変なところに飛びまくる、という現象。なので、この辺からも、テンポラリファイルの処理がなんかこけているのではないかなぁ、と推測はしているのですがね。
とにかく、でかいファイルをぶん回すのが面倒なんでね。事象の再現する、できるだけ小さいファイルはどのくらいなのかということを確認したいわけなんです。

[4796] Re^2: Ek-(追試3)

文太 2022/06/19(Sun) 22:33
[4795]へのコメント
としきさん

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


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、オープン状態です。
 テンポラリーファイルがEMSに行ってる。「ここで落ちるな、VTDOS」とか祈ってました。
 swap.asmとかも、ありましたね。

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

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

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

[4799] 一人遊びです m(__)m: swap.asm

文太 2022/06/20(Mon) 00:39
[4796]へのコメント
 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さんみたく、テキストと戯れるのが好き
なんですよ。
 僕も宵っぱり、なのかな。

[4803] 一人遊び2(filemake.def)

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

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

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


=== 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】ヽ(^。^)ノ 終了!") .

*

[4807] Re: 一人遊び2(filemake.def)

としき 2022/06/21(Tue) 23:10
[4803]へのコメント http://toshiki.la.coocan.jp/
>  あのxxx.cgiとか、yyy.cgとかの中身が、うげげげげ、だったので、

そのお気持ちは理解できます。
ただ、全く異なったデータを使われてしまうと、同じデータによる各人の環境での挙動の違い、というのが検証できなくなってしまいます。と、私が考えるのも、単に私が理系思考に毒されているだけかもしれません。
また、そもそも#4635でkonnoさんから

> 同じ状況を再現するには、同じファイルでテスト出来ると助かります。

というご提案をいただいて提供しているファイルです。
逆に、同じ事象を再現できるファイルが共有できれば、うげげげげ、ではないファイルでも一向に構わない、というか。

ということで、例えばファイル中の2バイト文字の部分を全部、1バイト文字2桁に書き換えるマクロ、というのはいかがでしょうか。ん〜、2バイト文字を16進変換して、そのうちの下2桁、とか。例えば「あ」なら「a0」、「亜」なら「9f」とか。

[4810] Re^2: 一人遊び2(filemake.def)

文太 2022/06/22(Wed) 02:01
[4807]へのコメント
としきさん

 僕がとっても目的志向で、遊び(余裕)がないということなんだろうなとは思うのですが。

>例えば2バイト文字の部分を全部、1バイト文字2桁に書き換えるマクロ、というのはいかがでしょうか。
>ん〜、2バイト文字を16進変換して、そのうちの下2桁、とか。例えば「あ」なら「a0」、「亜」なら「9f」とか。

 僕なら、sedで正規表現を使って、2バイト→1バイトx2(決め打ち「00」とか)にしてしまうと思うな。最適な道具をまず選べ、とか思ってしまいます。
 目的志向なんですね。そこまでVzマクロにこだわらないと思う。
 逆に、makefile.defに2バイト文字を入れるのは簡単でしょう。
 僕には余裕がないんでしょうね。

[4812] Re^3: 一人遊び2(filemake.def)

としき 2022/06/22(Wed) 16:13
[4810]へのコメント http://toshiki.la.coocan.jp/
>  僕がとっても目的志向で、遊び(余裕)がないということ

なんとなく私と文太さんですれ違ってしまったような気がするのは、おそらく、私が文太さんの目的を理解できていないとか、あるいはそもそものところで、私の望む目的と文太さんの目的がすれ違っているとか、なんとなくそんなところだと思います。
私とkonnoさんで、おそらく合意しているであろう目的としては、異常と思われる動作が発現するファイルを共有すること、です。これはkonnoさんの#4635のご提案に基づきます。つまり、そもそもが異常なファイルなわけで、うげげげげ、であることは当初から想定されていること。なので、そんなファイルを欲しいと思っていない人が多数だと思っていました。逆に、怖いものみたさ、という人も多数いるかもしれない。


>  僕なら、sedで正規表現を使って

おぉ、そうだ、そういう手がありますね。
そんなことにも思い至らないなんて。
私のほうにも余裕がなさそうな感じです。

[4818] Re^4: 一人遊び2(filemake.def)

文太 2022/06/23(Thu) 11:49
[4812]へのコメント
としきさん

 #4807, #4812を読み返しました。
 対象ファイルの共有の意図、誤解したことはないです。大丈夫。でも、自分で論理行長とファイルサイズを自由にできたら、実験の幅が広がるかな、と(あまり広げないほうが良いと、現在は結論しています)。
 で、意図のすれ違いは、そして僕が「その余裕はない」と思ったのは、さらに拡張して遊ぶということです。つまり、2バイト→1バイトX2のマクロを書くということ。これは、僕の感覚では、えらく問題解決路線からは離れてしまう。できても、そのマクロの存在意義が分らない。
 もちろん、swap.asmは最初からあったのか、というのは3万年光年くらい問題からは離れた、はた迷惑な「お遊び」ですが。文太は、いつもやってる。これは事実。

 で、問題解決のアプローチを僕が変えたのは、結論はひどく雑駁で曖昧だけど、これ、オリジナル・エスキだけの問題でない、論理行長のどの辺で、Vzは根をあげるのか? オリジナル・エスキがいちばん弱いみたいだけど、と考えたから。
 僕は、その程度なんだ、いちおう気にしておく、ということで、少し納得しました。

 としきさんは、個別に、もっとずっと正確に精密に追い込みたいんでしょうね。ただ、思うのは、0007.cgi(および類似ファイル)は、いろんなところで、Vzの限界を超えてしまっているファイルなんだろうな、ということです。不具合がいっぱい出るのでしょう。

[4828] 全角→半角。闇&病み

文太 2022/06/24(Fri) 16:31
[4818]へのコメント
--- 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に含まれているの
だもの。「訳が分らない」という結論は、はい、忘れていましたが、この
プロジェクトに参加する以前から(ほぼ経緯を知らなかったのに)知っては
いましたが。
 僕のアプローチは「地雷の近くには近づくな。地雷敷設位置だけ、ある程度
知っておけ。踏んじゃったら、しょうがない。命は取られないから大丈夫」
です。

[4830] 追伸

文太 2022/06/25(Sat) 00:28
[4828]へのコメント

 必死に想像すれば、想像は可能だと思うのですが、たぶん、ふつう無理だろうと思うので、いちおう書いておきますね。XPやVTDOS環境なら窓が飛ぶだけなのですが、WinMEではマシンフリーズなんです。
 このところ3〜4年、経験してないので、心臓に悪いのです。

[4800] 行ブロックズレはマクロのせい?

konno 2022/06/20(Mon) 01:09
[4795]へのコメント
> この問題に、ついに文太さんまで巻き込んでしまいましたね。

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

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

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

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

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

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

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

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

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

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

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

(cd==13)??#<

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

[4801] Re: 行ブロックズレはマクロのせい?

としき 2022/06/20(Mon) 13:31
[4800]へのコメント http://toshiki.la.coocan.jp/
> VZの問題はみんなで共有した方がいいかと思ったもので。(^^;

その判断に問題はないと思います。
ただ、多忙その他で手を出せなかった方に無理に押し付けるような形になりはしないかと、そこの部分で私は二の足を踏んでいました。

> (cd==13)??#<

いいですね、これ。
これで解決できるようなので、現在継続中の追及作業が終わったら導入しようと思います。
ただ

> 本来なら行頭にくるはずなんですが、1文字ズレることがあるんですね。

こちらが根本原因なので、これの原因が判明するか、あきらめるか、飽きるか(笑)するまでは、1文字ずれを追及し続けたいかな、と。

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

この辺、マクロの挙動のほうはめざらさんにわかるかなぁ。
めざらさんにもわからなければ、現在では誰にもわからないかも。

[4804] 解決!

文太 2022/06/21(Tue) 00:04
[4800]へのコメント
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さんのマクロも、上村さんのマクロも、お手本ですね。
 だいたい読めたのが驚き。

[4835] Re: 行ブロックズレはマクロのせい?

めざら 2022/06/27(Mon) 16:22
[4800]へのコメント http://mezala.la.coocan.jp/
わたしは,マクロが原因ではないと思います。
> Ek- の時カーソル位置更新しますが、その位置が1文字ズレて改行の所になります。

「カーソル位置に挿入」([ESC]I) は元々行ブロックのみを扱っています。
なので,厳密に言えば「カーソル行頭」への挿入なのですが,ブロックペースト後のカーソルがずれて中間処理分ブロック末尾行の行末に移ってしまうことが原因ですよね。

現象から言えば,確かに #< があることで論理行が入れ替わるということになりますが,不具合の根本的な因子はそこではないと思います。

以前にもちょこと書きましたが,#< にはページングにおける KY (保存されたY位置)を更新する効果があって,ヒトの目線のズレ修正に貢献していると考えているのですが,c.mosさんとしては「美しい動作」というのが脳裏にあって #< を使っていたのではないかと想像しています。(まるきり外してるかも)

行ブロックしか扱わないから最初に一度だけカーソルを行頭に置けばいいように思いますので,冒頭の &m() の前後あたりに #< を書き,他の2箇所の #< を取ってしまうとか。

ただ,それをすると別の問題が起こる可能性もあるかもしれません。カーソルがずれて行末にあれば,#< があろうがなかろうが論理行入替えは発生する可能性が限りなく高いはずだからです。

[4837] Re^2: 行ブロックズレはマクロのせい?

konno 2022/06/28(Tue) 01:16
[4835]へのコメント
> 現象から言えば,確かに #< があることで論理行が入れ替わるということになりますが,不具合の根本的な因子はそこではないと思います。

まあそうなんですが、ファイルが壊れる場合と行が入れ替わる場合と文字化けのパターンがあるみたいなので
そのうちの行入れ替わりは #< の影響があるのかなと思ったのです。

> 以前にもちょこと書きましたが,#< にはページングにおける KY (保存されたY位置)を更新する効果があって

なるほど、そういう意味なら納得できるような気がします。

> ただ,それをすると別の問題が起こる可能性もあるかもしれません。カーソルがずれて行末にあれば,#< があろうがなかろうが論理行入替えは発生する可能性が限りなく高いはずだからです。

これも納得です。#< を弄っても意味がないということですね。

[4797] Re: Ek-(追試3)

konno 2022/06/19(Sun) 23:28
[4791]へのコメント
文太さん、WinMEは化けて、Win7は化けなかったのですか。
私は逆を予想していました。
環境によってやはり違うのですね。

[4792] 【まとめ】

文太 2022/06/19(Sun) 12:23
[4783]へのコメント

 今回の不具合は、最低限、以下の条件を満たすと再現できる。

 ・ある長さ以上の論理行の入ったファイルが対象であること。(注)
 ・#Bを含むオリジナル・エスキ・デフを使うこと。
 ・Ek−のこと。
 ・Bl8192のこと。

(注)
2022/06/19  12:06    6,593 0007-i.out
 これは、0007-i.cgiの最大長行だけをnagasa.defで残したもの。詳細を調べたり考えたりするつもりはありませんが、少なくとも 6593 bytesぐらいの長さの行が含まれていると、やばそうですね。もしかしたら、5000 bytesが3つ以上(連続とか?)だと、出る、とかもあるのかもしれません。

 konnoさん、深夜までお付き合い、ありがとうございました。

[4798] Re: 【まとめ】

konno 2022/06/19(Sun) 23:58
[4792]へのコメント
>  ・ある長さ以上の論理行の入ったファイルが対象であること。(注)
>  ・#Bを含むオリジナル・エスキ・デフを使うこと。
>  ・Ek−のこと。
>  ・Bl8192のこと。

Bl の数値を変えると結果が変わってくるので、行の長さは関係していそうですね。
あと、64k以上のファイルが条件だと思います。
ブロック範囲を超えて複数回挿入することで発現するみたいなので。

nagasa.def 役に立ちました。紹介してくれて感謝です。

>  konnoさん、深夜までお付き合い、ありがとうございました。

深夜というか、単に私が宵っ張りになっているだけだったりして。(^^;

[4808] Re: 実験は試みたけど

としき 2022/06/21(Tue) 23:20
[4783]へのコメント http://toshiki.la.coocan.jp/
nagasa.def、こんなマクロがあったのですね。
もしこのマクロを知っていれば苦労しなかっただろうに、という案件があったはず。もう十数年前、21世紀初頭のことなんで、詳しいことは忘れていますがね。
そのとき、どのように解決したかというと、awkを使って行頭に長さのフィールドを追加、そのフィールドを使ってソート、最後にsedで行頭の長さフィールド削除、とやっていました。

ん〜、事象の出る最小の.cgiファイル、そしてもともとの0007.cgiも、nagasa.defを使って行長順にソートして、それでも事象が再現するか、あとで試して見ます。今日はもうしないというかできないというか。アルコールが入っているもので。

[4811] Re^2: 実験は試みたけど

文太 2022/06/22(Wed) 02:10
[4808]へのコメント
としきさん

>そのとき、どのように解決したかというと、awkを使って行頭に長さのフィールドを追加、そのフィールドを使ってソート、最後にsedで行頭の長さフィールド削除、とやっていました。

 僕も同じような発想をしていました。ただ、いまでも、「行長でソート」の意味というか実用性がよく分かりません。分らないよ、という記憶があったから、このマクロを思い出したのだと思います。

 で、よく意味は分からないけど、このマクロがなかったどうしたろう? と考えたとき、まっさきに考えたのが、上のとしきさんの考え方でした。おお、やっぱりそうなの?! というのは嬉しかったです。

[4814] Re^2: 実験は試みたけど

としき 2022/06/22(Wed) 23:19
[4808]へのコメント http://toshiki.la.coocan.jp/
> nagasa.def、こんなマクロがあったのですね。

nagasa.defについて、いくつか。
このマクロ、起動するといきなり保存してくださるのですね。
タイムスタンプが変わってしまって、ちょっとびっくり。
というか、私、ファイラーを日付順にしているので、このファイルはどこにいったと探し回る羽目になってしまいました。すなわち、実害あり。
ま、内容が変わるわけではないので被害は少ないといえば少ないのですが、人によってはとてつもなく大きな被害をもたらすはず。例えば、タイムスタンプに応じて何かをする仕組みを構築している人とか。アセンブルするのにmakeを使っている人とかね。
エクスキューズになるようなドキュメントの記載もないし、これはちょっと、私にとってはイマイチなマクロ、という感情を抱きました。

そこでさっくりと、マクロ冒頭の#S #mをコメントアウトしたわけですが、これって何か不都合が発生するでしょうか。というか、何らかの理由があって作者は編集フラグとかを参照せずにいきなり保存するようにしてあるわけで、それにもかかわらず、その保存機能を有無を言わさず潰す、というのはちょっと怖い。

次。
#4802の最後に書いた0010.cgiをnagasa.defで処理してみました。
まず、天地反転した0010r.cgiというファイルを作成。
おや、1バイト小さい。27980バイトになってしまった。
どこかの改行コードあたりが削除されたのかな?
で、まぁ、このファイルを開き、ファイル冒頭で0007.cgを挿入。結果、異常挿入。
続いて、0010.cgiを短い順でソートした0010s.cgiというファイルを作成。
これは1バイト小さくならない。27981バイトのまま。
そしてこのファイルを開き、ファイル冒頭で0007.cgを挿入。結果、異常挿入。
最後、0010.cgiを長い順にソートしようとして

・・・

帰ってきません。
なんか、どこかで止まってしまったみたい。
これからちょっと、頭を冷やすために体を温めるというか、入浴してきます。
風呂から出てもまだ終わっていないようなら、&sを潰してから再実行し、どこで何がおかしくなるのか観察してみましょう。

[4815] やはり論理行長?

文太 2022/06/23(Thu) 01:29
[4814]へのコメント
 作業をダイジェストすると、挿入ファイルも被挿入ファイルも80字で桁折りして
c.mos版エスキをしたら、どうなる? ということ。
 結果。成功。
 やっぱり、きっと、論理行長が長すぎたのだろう。

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

s/\(................................................................................\)/\1#&あs\
/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 に桁折りし(80字)、同様に
 0007.cg  を 0007_.cg  に桁折りし(80字)、konno修正を外した、オリジナル
エスキを施し、怖かったけどそれしか手がなかったので、Vzの置換で、「#&あs\n」
という行末マークを外した(テキストバッファ、がんばれ!)。

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

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

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

[4817] どこが限界?

文太 2022/06/23(Thu) 10:46
[4815]へのコメント
 アプローチを変えました。
 論理行はどのくらい長くても、Vzは耐えられるのか?
 c.mos版オリジナル・エスキだけでなく、Vzのいろんなところが。
(#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、エスキ、置換(Vz)、go2.bat の順番で、【それぞれ】実行。
 1280文字ということは、最大で、2560 bytes。
 insfile.defなら問題ないが、original ESCIでは問題が出るのは、意外に
早い。

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

[4816] Re^3: 実験は試みたけど

としき 2022/06/23(Thu) 02:10
[4814]へのコメント http://toshiki.la.coocan.jp/
> 風呂から出てもまだ終わっていないようなら

終わっていませんでした。
そこで、軽くトレースしてみたところ。
最後、4番ローカルの改行変換処理のところで延々と無限ループしている。
天地反転で1バイト短くなるというところも含め、どこかの改行コードが普通でないのかもしれない。
挿入異常の原因も改行コードが原因だった、なんてことだったりして。
高々20行にも満たないファイルなんで、すなわち改行の個数もそんなに多くないので、全ての改行コードをもう一度洗いなおしてみましょう。

とりあえず、今夜はもう寝ます。あぁ、日勤だから5時起床だ。

[4819] 0007.cgiなどの改行

文太 2022/06/23(Thu) 16:08
[4816]へのコメント
>挿入異常の原因も改行コードが原因だった、なんてことだったりして。

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

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」で改行の数をカウントした結果です。

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

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

[4820] Japanized SED, outfile = \n

文太 2022/06/23(Thu) 17:04
[4819]へのコメント
 ふと気になりました。ほんとに、LFのみ、CRのみで入ってきたテキスト
ファイルの出力も、SEDはCRLFにしてしまうのか? 結果:します。

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

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

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

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

[4821] Japanized Sed と type (on Win) は違う

文太 2022/06/23(Thu) 23:37
[4820]へのコメント
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 コマンドとは、
やはり違いますね。

[4894] GNU sed の現在

文太 2022/08/03(Wed) 21:16
[4820]へのコメント
 ちょこっと落書きです。あれ以来、すっかり 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 でOK.

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でした。

[4895] 追記:やっぱダメだと思う

文太 2022/08/03(Wed) 23:09
[4894]へのコメント
#>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

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

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

[4896] Re: 追記:やっぱダメだと思う

めざら 2022/08/04(Thu) 08:26
[4895]へのコメント http://mezala.la.coocan.jp/
HP200LXが使えなくなった今,onigsed以外の選択肢はあるのかしらん?

あ,そうか,dosvaxj3 環境だとセローさんになるんだな〜。

[4897] Re^2: 追記:やっぱダメだと思う

文太 2022/08/04(Thu) 12:30
[4896]へのコメント
>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変えてます)
 がおすすめです。@ベクター

[4898] multi-byte sed for win

文太 2022/08/04(Thu) 17:07
[4897]へのコメント
 ああ、いえいえ。
 気づかせていただきまして。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 って、2種類あるみたいじゃん、と
気づきました。上の「GSED3.EXE」は、VTDOSでは使えなかったとあります。
ここのところ、vtdos @ win7で、破線下の sed32.exeをよく使っています。
とりわけ「stack overflow」とか言われることもなく。

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

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 サイズのほうです。

[4899] sed for dos (16 bit)

文太 2022/08/04(Thu) 22:28
[4898]へのコメント
 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
 あまり参考になりません。日本語を処理してくれないと、なので。

[4902] Re: sed for dos (16 bit)

文太 2022/08/08(Mon) 01:16
[4899]へのコメント
 いちおう修正しておきます。

  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

[4903] Re^2: sed for dos (16 bit)

めざら 2022/08/08(Mon) 10:44
[4902]へのコメント http://mezala.la.coocan.jp/
追加修正表,ありがたいです。

こうして見ると,やはり使い慣れていることの理由がわかりますね。
やりたい処理があって,それを実現してくれる処理系を選択する。
…という流れの結果というか。

Perl風の拡張正規表現を必要とする機会はあまりなくて,わかりやすく書けるものを選択しているのだろうな,と思います。
でも,最近は概ね置換だけだけれど。

テキスト処理……ソート,ユニーク,定型置換など……は,もっぱらクリップボードに格納したものを処理して入れ戻すバッチのショートカットをスタートメニューに置いておくという方式で大抵は間に合っています。

寅次さんの Clppst.exe がなかったらいちいちテキスト保存するという手間が必要ですが,本当に寅次さん様々ですよ。似たようなツールはあるのかもしれないですが,使い方のわかり易さ抜群ですし,信頼性も高いので本当に素晴らしい。

Si さんの TU.exe や SSORT.exe も忘れちゃいけない。RCP.exe も。

[4904] Re^3: sed for dos (16 bit)

文太 2022/08/08(Mon) 23:58
[4903]へのコメント
めざらさん

>やりたい処理があって,それを実現してくれる処理系を選択する。
>…という流れの結果というか。

 そうですね、僕は、sedに関してはどちらかというと、「やりたい処理」より、「やりたかったのにやれなかった処理」にむかっていて、けっこうオタクっぽいのかも。最後の最後にVzマクロです。これなら、(面倒で時間がかかることも多いけど)最終的には、ぜったい結果を出せます。

>Perl風の拡張正規表現を必要とする機会はあまりなくて,
 これについては、パイプを通して、2回3回と処理を分ければいいか、となっています。
 これ、ほんとに多いパターン。1本のスクリプトでやろうとするからそうなるんじゃん、とついつい考えてしまうこと、多いです。でも、そんな模範解答スクリプトをかっこいいなぁ、とも思ってしまうのですが。

http://www.rtfiber.com.tw/~changyj/sed/
 最近、接続が悪いのですが(ぜんぶローカルに保存してある)、これ、すごいです。


>テキスト処理は,もっぱらクリップボードに格納したものを処理して入れ戻す
 それをやってるんですか。ときどきふとそれが楽じゃない? と思うこともあるのですが、やったことないです。愚直にテキストに落としてから、じいっとテキストを見つめてますね。何を使うんだ? と。

 そういう意味では、「寅次さんの Clppst.exe」は、ゼッタイの地位を占めてますね。1回メモ帳とかでテキストに保存してからとかしてたら、さすがに「秀丸」のマクロを覚えたほうが早いぞ、ととっくの昔に思っていたかもしれません。
 とらじさんものとしては、わりと最近、taglight.exeに感動しました。
 まだ足りないけど、それそれ、と。

s/^\(From: [^\n]*\n\)\(Subject: [^\n]*\n\)\n\((03) [^\n]*\)$/>\1>\2>\3/

 これが
--- taglight.pat ---
#sed/awk/def
C /
C (
C )
--------------------

 で着色されてます。 自分でちょっと前に書いたスクリプトなのに、ど、どこまでが検索文字列ですか? どっからが置換文字列ですか? とうんざりしたので(行内の「/」を飛び回るマクロを最近かき、^W のキーを与えました)。

 とらじさん、ほんとうに神様ですね。


 Si ツールズとしては(同じく神様です)、RCP.exe ももちろん、ほぼ空気のように「ありがたやm(__)m」なのが(環境派なので、空気と水と土と太陽を信仰しています)、wild.exeだなぁ、僕的には。

Wild -D -R "head -7 $f >c:\wk\$x" c:\bin\asm_stdy\*.doc
Wild -D "Oldsed -f 0.sed $f >c:\wk\$x" c:\bin\doc\dos_help\*.txt

 なんてのが、wild.docの先頭にありました。
 logosさんも頑張りましたけど、フィルター系って、入力がワイルドカード展開で複数ヒットしてくれても、出力が1つになってしまうので、wildのマクロ機能が、もう、堪らないのです。

[4905] ホールドスペース四方山話

文太 2022/08/09(Tue) 14:54
[4904]へのコメント
 めざらさん宛ではありません。
 ま、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行目以外はHSの文字列をPS文字列にアペンド
h				#PS文字列をHSに保存
$p				#最終行でPS(反転された全行)を出力
-----

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

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

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

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

[4906] ファイル末改行(ありなし)

文太 2022/08/09(Tue) 15:13
[4905]へのコメント
 四方山話をもう一つ。もちろん、sedがらみです。

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

 結論:

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

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

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

[4907] Re: ホールドスペース四方山話

文太 2022/08/09(Tue) 23:03
[4905]へのコメント
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

[4900] 『やっぱダメ』の意味はわからないけど

めざら 2022/08/06(Sat) 09:42
[4897]へのコメント http://mezala.la.coocan.jp/
おお,そういえば LOGOS さんてのも有りましたね。
一時期さかんに使わせてもらっていたような気がしますが,どうして使わなくなったんだっけ……思い出せないや。NEC-98専用?んなことないか……

sed で改行を扱おうとすると,まるでスクリプトの途中で間違って改行しちゃったんじゃないかみたいに見えて違和感が半端ないんですよね。

でも最近はすっかり置換専用(特にyコマンド)になってしまって,セグメントを操作するようなことはしなくなっちゃいました。

仕事から退いて便利ツールを業務端末に設置するなんてこともなくなったからです。一応見どころのある後継者が二人いて,ボランティアに行くと質問とかしてくれるのですがね。それでも,「面倒くさい」を解決しようとする意識って,もうほとんど失われていますね。
業務効率化というのは結局,中途半端に手を抜いて放置することになっているようにも見えます。仕事は増やされる一方で,不要と思われる業務を廃止する判断をする管理職がいないので,ちゃんとやっていたらいくら残業しても足りないという状況。あ,野良犬の遠吠えにしかなってませんね。中間管理職は仕事をこれ以上増やされないよう頑張っているのに。
現場は大変です,うん。

[4901] Re: 『やっぱダメ』の意味はわからないけど

文太 2022/08/06(Sat) 22:35
[4900]へのコメント
 やっぱりダメなのは、
gnu sed 4.2
に日本語を扱わせるのは色々たいへん、という意味です。1文字にヒットさせるのに、「..」となったら、もうダメです。(see #4894

 うーむ、やっぱり全体にパイが少なくなっている状態で、そういう意味では若い人たちにはかわいそうな面がありますね。
 一方で「おい、そういういい加減な仕事の仕方あるかよ」と思う場面もあり、同時に、「さっすがタフな状況で育ってきたから、半端ないですね、君たち」と思う場面があります。
 僕にとって若い人というのは、ロスジェネ世代だったりします。もっと下はまだあまり付き合いがないのです。
 僕の時代、30歳までに就職できればいいよ だったのに、
 昨今では、40歳までに就職できたら勝ち組 みたいな世界なので。

 yコマンド(1文字の置換!)と(単純な)sコマンドだけなら、きちんと検証すれば、onigsedでもいいのかもしれません。

s/^\(From: [^\n]*\n\)\(Subject: [^\n]*\n\)\n\((03) [^\n]*\)$/>\1>\2>\3/

 こんなのになってくると、万が一、sed.com/exe のほうにバグが疑われたら、そんな道具を使う気にはなれないですよ。
 これはserowさんでも通るはずですが、

s/^\(From: [^\n]*\n\)\(Subject: [^\n]*\n\)\n\((03) [^\n]*\)$/>\1\
>\2\
>\3\
/

 こうなると、もうserowさんでは嫌ですよねぇ。

s/^\(From: [^\n]*\n\)\(Subject: [^\n]*\n\)\n\((03) [^\n]*\)$/>\1>\n\2>\n\3/

 って書かせて、と言いたくなります。

[4825] 改行置換

としき 2022/06/24(Fri) 11:35
[4816]へのコメント http://toshiki.la.coocan.jp/
> 全ての改行コードをもう一度洗いなおしてみましょう。

文太さんにも洗いなおしてもらったようですね。ありがとうございます。
私のほうでも、改行コードに問題はありませんでした。
そこで、トレースと途中停止を駆使して調査した結果。
私の検索オプションのせい、ということがわかりました。
具体的には、過去にも話題になったことがあると思いますが、全角半角同一視の設定。空行削除をしようと \n\n を \n に置換する場合、全角半角同一視の設定があると、ファイル先頭の空行にマッチしたことになってしまうようで、置換1回という結果が返ってきます。でも、実際には置換が行われない。
そして、置換が0になるまでループ、というコードは破綻をきたすわけです。
えと、これってVWXのバグなんでしたっけ。

そして、何でファイル冒頭に空行が入ってしまうのかというと、こちらのほうが0010.cgiファイルの問題の根本原因のような感じです。
こちらについては発言を分けます。

[4831] Re: 改行置換

としき 2022/06/25(Sat) 13:12
[4825]へのコメント http://toshiki.la.coocan.jp/
> 何でファイル冒頭に空行が入ってしまうのか

こちらの原因は全くつかめていないのですがね。
何回もnagasa.defを起動していて発生した妙な不具合がありまして。
14行目になるのかな、「2617」で始まる行。
行末に行長のカラムが付加されますよね。
通常なら「2138」という長さになるはず。
ところが時々、この値が「-1721」という不正な値になるのですよ。
この値はcpを使って求めているはず。
これの再現条件がわかれば、ここを突破口に、あちこちの行の長さを変えたりバッファのサイズを変えたり、ということができそうなんですが、あいにく、いまだにさっぱり。

もうちょっとはからかってみますが、何らかの結論が出ない場合、nagasa.defの方面から攻めるのはこの週末で終わりたいと思っています。もちろん、何かわかれば、その方面からグイグイと。

[4832] Re^2: 改行置換

konno 2022/06/27(Mon) 00:55
[4831]へのコメント
> ところが時々、この値が「-1721」という不正な値になるのですよ。
> この値はcpを使って求めているはず。

:L #< c=cp, ;c line_head offset
#> l=cp-c, ;l length

ここですね、行の長さを cp で求めていたとは。
cp を使った計算だと、マイナスになることがあるのでは?
これは64k超のファイルではまずい気がします。
マイナスになったら補正すればいいのだろうか?

[4834] Re^3: 改行置換

としき 2022/06/27(Mon) 01:06
[4832]へのコメント http://toshiki.la.coocan.jp/
> これは64k超のファイルではまずい気がします。

今回、32kに満たないファイルでマイナスになることがあるのですよ。
そしてその原因は不明。
追及しようとするとするりと逃げられる。
そして#4814にも書いたけど、このマクロ、私にとっては他にも不便なところが多くて。そもそも長さ順ソートなんて数年に1回程度の頻度ですが、このマクロは封印してもう使わない方向。もちろん、手を入れることは可能かもしれないけど、そこまでして使うようなことはないでしょう。

[4836] Re^4: 改行置換

konno 2022/06/28(Tue) 00:34
[4834]へのコメント
> > これは64k超のファイルではまずい気がします。

32k の間違いでした。
cp も汎用変数も 32k $8000 で -32768 になるんですね。
境界をまたぐ場合は誤動作するような気がしますが。

> 今回、32kに満たないファイルでマイナスになることがあるのですよ。
> そしてその原因は不明。
> 追及しようとするとするりと逃げられる。

うーむ、処理中に各行のお尻に、マーク文字と長さを追加してますね。
&?("%d",l) ;at line tail,冢nn・・・mark
このせいで32kオーバー・・・は無いか、15行程度じゃ。

本筋から外れるので私もこれ以上は追及はしないつもりですが、気が向けばもしかしたら。

[4838] Re^4: 改行置換

めざら 2022/06/28(Tue) 18:38
[4834]へのコメント http://mezala.la.coocan.jp/
> 今回、32kに満たないファイルでマイナスになることがあるのですよ。

もしかして,ラインバッファに入っちゃってるってことないでしょうか。

行編集操作が入れば,cp はラインバッファのオフセットを指すことになるので,32kbに満たないファイルでも cp が $8000 の境界をまたぐことがあり得ます。

ただ,先般拝見したとしき環境の csegmap を見る限り,$8000 をまたいでいるのは各種文字列履歴バッファのいずれかなので,可能性は低いため謎ですね。

製品版環境(COM and DEF)だとしたら,上記の可能性が高くなります。

[4839] Re^5: 改行置換

としき 2022/06/28(Tue) 23:46
[4838]へのコメント http://toshiki.la.coocan.jp/
> もしかして,ラインバッファに入っちゃってるってことないでしょうか。

これを確認するにはどうすればいいのでしょうか。
と伺っても、何かを確認するためのコードを入れると事象が再現しないことが多いわけで、結局確認できなさそうな気がする。
アレだ、観測という行為そのものが現象に影響を与える、ってヤツ。
不確定性原理、でしたっけ。

とりあえず、この現象は私の常用環境で発生しています。
製品版環境では、nagasa.defを試してもいません。

[4833] Re^2: 改行置換

としき 2022/06/27(Mon) 00:59
[4831]へのコメント http://toshiki.la.coocan.jp/
> nagasa.defの方面から攻めるのはこの週末で終わりたい

終わります。
トレースしたり条件付きでcpの値を表示させたりと、網を張ってもまったく引っかからない。でも、網を外すと、そこそこの確率で異常は起きる。そして、そこそこどころではなく非常に高い確率で、ファイル冒頭に空行は入る。そして、こっちの原因も不明。
もうやめ。



一応、今後の方向。
#4780に書きましたが、0007.cgiの先頭から15行目までの途中に改行を入れて、そこから後ろを全て削除した27981バイトのファイルでは異常挿入が起きました。そこからさらに表示行で1行、80バイト削った27901バイトのファイルでは、異常挿入が起きません。
そこで、この27981バイトのファイルを、私はこれより0010.cgiと呼称することにします。
まずはこの0010.cgiをさらに削っていき、異常挿入を起こす0007.cgiの冒頭からの真の最小のファイルサイズを見つけたい。そして、その境界の値が見つかったら、例えば1行目や2行目の行の長さをプラスマイナスさせて、そこが本当に異常動作の境界になるのかチェック。他の行をもっと削りまくっても異常動作が起きるとなると、それはそれで興味深い。
あと、今回のnagasa.def関係の調査の過程で、0010.cgiを行の長さの長い順、および行の長さの短い順にソートしたファイルを入手しました。これらにはとりあえず、0010L.cgiと0010S.cgiという名称を付与してあります。これら2つのファイルでも、ファイル冒頭に0007.cgiを挿入しようとすると異常挿入になりました。そこで、これら2つのファイルも、先頭から、または末尾から削除を行い、どこまで小さいファイルサイズで異常挿入が起きるか、というところを追及してみたいと思います。
直感では、5行目くらいにある4キロバイトを超える行、この辺が怪しい気もしますが、はたしてどうなりますやら。


実は私も文太さんと同様、あまり地雷に近づきたくはないのですがね。
でも、私は文太さんと違って、地雷がありそうな範囲をなるべく狭く確定させたい。なぜそういう考えなのか自問するに、そうすれば、逆に地雷がない部分が広くなって、それはすなわち、自分の自由度が高くなることに他ならないから、という気がしています。あとづけの理由かもしれませんけどね。
余談ですが、マインスイーパーは今のWindowsにもデフォルトで入っています。
Win3.1以降、遊ばせてもらっています。DOS版のフリーウェアでも遊びました。
Vzマクロでもありますよね。
だからなんだ、という話ですが。

[4840] Re^3: 改行置換

としき 2022/06/29(Wed) 00:41
[4833]へのコメント http://toshiki.la.coocan.jp/
いろいろと遊んでいます。

> 異常挿入を起こす0007.cgiの冒頭からの真の最小のファイルサイズ

見つけました。
27932バイトでは異常発生、27931バイトでは正常挿入。
続いて、この27932バイトのファイルで一番長い行である5行目、適当なところに改行を入れて27934バイトにしたファイルを何種類か作ってみたけど、全て異常発生。どうやら、この行が長すぎるのが原因、というわけではないらしい。
また、長い順ソートも短い順ソートも、いずれも27932バイトでは異常発生、27931バイトでは正常挿入。後ろから削っても前から削っても、状況は同じ。
ん〜、予想は外れたか。
どう予想していたかというとですね。
ファイルの先頭に挿入するわけですから、既に開いているファイルは後ろにずらす必要があるわけですよね。この、ずらしの際に、Blか何かのバッファのサイズと改行の関係があって、長すぎる行のところでこけているのではないか、と考えていたわけです。なので、長い順ソートや短い順ソートで挙動が変わるのではないか、と予想していたのですが、あっけなくハズレ。

上記のとおり、27932バイトのファイルで異常が発生しています。
そこで、ためしに2048バイトで桁折してみました。
当然、いくらか改行が追加されるので、ファイルサイズは膨らみます。
でも、最大行長は短くなるので異常は発生しなくなるかな、と期待したのですが、無事に?異常挿入。
では、どこまでファイルサイズを削れば正常挿入になるかと試してみたところ、なんと、やっぱり27931バイトで正常挿入。

桁折については、#4802で報告していますが、0007.cgの側を桁折したら1桁で桁折したファイルでも0007.cgiに挿入しようとしたら異常挿入でした。そこで今度は0010.cgiのほうを1桁で桁折したら正常挿入。12桁でも正常、18桁で異常。この18桁での異常というのは、普通に異常というか、今まで見慣れたパターンでの異常。
ところが、です。
14桁とか16桁で桁折した場合、今までとは違ったパターンで異常。どう異常かというと、0007.cgの、行の中間でぶちきられる、という状況。おぉう、これはすさまじい異常だ。


ということで、今後の方向。
上記の、桁折した場合の異常挿入について、[ESC]Iのマクロにトレースを入れたりして、もうちょっと詳しく見ていきたいと思います。
また、桁折でむちゃくちゃ異常になるところとは別に。
桁折する前の.cgiファイルの、異常挿入を起こす最小のサイズは27932バイトだとわかったので、こちらはこの値で固定。そして.cgiファイルではなく.cgファイルの側のサイズだとか行長だとかをいじって、異常挿入を起こす最小の.cgファイルのサイズ、みたいなものを求められたら求めてみたいと思います。あるいはさらに0007.cgiまで遡って、このファイルに異常挿入を起こさない.cgファイルのサイズ、なんてものと比較したい気もするけど、はたしてそこまで手が回るかなぁ。

[4841] Re^4: 改行置換

めざら 2022/06/29(Wed) 01:15
[4840]へのコメント http://mezala.la.coocan.jp/
> いろいろと遊んでいます。
 このポジティブ思考が救われます。

> 上記のとおり、27932バイトのファイルで異常が発生しています。

> 試してみたところ、なんと、やっぱり27931バイトで正常挿入。

 この境界は一体なんでしょうね。
 27932 == $6D1C … 4では割り切れるが,それ以上の倍数と関係なし。

 別の環境で試してみる必要があるでしょうか。

[4842] 再確認、失敗(0007.cgi 最小サイズ)

文太 2022/06/29(Wed) 21:11
[4840]へのコメント
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

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

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

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

[4844] Re: 再確認、失敗(0007.cgi 最小サイズ)

としき 2022/06/30(Thu) 11:20
[4842]へのコメント http://toshiki.la.coocan.jp/
>  僕の視点(経験)からすると、挿入成功なのですが、手順が間違って
> いないことだけ確認させていただけますか?

手順はあっていると思います。

>  ところで、としきさんが「異常挿入」と言うばあい、挿入自体はされ、
> Vz、窓などが飛ぶということはないのですか?

挿入自体はされる、といっていいんだろうなぁ。
とにかく、その挿入の結果が正しくないわけで。
いろいろと手順を変えて何回もやっているわけですから、時にはVzや窓が飛ぶこともまれにあります。ただ、それを再現しようとすると、何が悪かったかわからないので再現できない。
最近だと、command.com窓で桁折ファイルに挿入しようとしたら、何かいきなりコマンドプロンプトになって、そこでいきなりexitとやったら窓が閉じたので、この結果から考えて、command.com自体が落ちてcmd.exeまで抜けていたようです。
あるいは、vtdos1.22でVzが固まることもまれにありましたが、これはマクロが無限ループに入っているのか、何がどうなっているのかわからず、右上の×ボタンで終了させたこともあります。
ほとんどWinXPで試していて、ごくまれにWin7とかWinVista、もっと少ない頻度でWin10のDOSVAXで試していますので、マシン自体のフリーズという事態にまで至ったことはありません。PC-98のDOSで試したのは1回だけで、そのときはフリーズしませんでしたが、Windowsでの経験から考えて、フリーズする確率は低いのではないかなぁ。

[4845] Re^2: 再確認、失敗(0007.cgi 最小サイズ)

文太 2022/06/30(Thu) 14:53
[4844]へのコメント
としきさん

 海豹牧場の写真、拝見しました。ちゃんと画面キャプチャーしてある!
 ただ、僕はあれらの光景をほぼ見たことがありません。
 もちろん、Win7マシンでOSまで飛んだことはないと思いますが、挿入失敗のときには、おそらく画面がピカッと光って自動で(!)閉じるか、Xを押すしかない事態に陥っていて、失敗の風景を見たことがないんですね。WinMEでは、おそらく100%マシンフリーズでしょう。

 逆にいうと、この掲示板ログの中身、気持ち悪いのですが……、という感想を持てたとき、つまり挿入に成功したときしか、ファイルの中身が見れたことがない、ということです。

 ということは、「失敗」と言っても、壊れ方は(ファイルにせよVZにせよVTDOSにせよOSにせよ)、けっこうヴァリエーションがあるんだろう、と想像しています。

[4846] 異なる現象の多重出現

めざら 2022/07/01(Fri) 11:25
[4845]へのコメント http://mezala.la.coocan.jp/
>  ただ、僕はあれらの光景をほぼ見たことがありません。
 それは祝着というしかありませんが,たぶん扱うファイルの大きさとか,同時に開くファイル数とか,ファイルの性質とかの条件をうまくかいくぐっておられるのでしょうね。

 ヴァリエーションから類型を考えると……
・テンポラリファイルエラー(昔からけっこうある)
・DOSエミュレータ環境との相性(メモリ操作で通らない命令があるのかも)
・ブロックポインタ不具合(今回「発見」されたと思しきもの)

 三番目は巨大(行)ブロックの扱いで,中途段階のブロックエンドポインタが前の行末にずれることにより,行ブロックの挿入位置が1論理行ずれてしまう現象。

 本来はこの現象の再現性を確認したいのに,その他のエラーも随時からんできて訳がわからない,調査が進まない,条件が確定しないというジレンマに陥っているわけですね。

 そこを,としきさんがかなり詰めてきているので,もうちょっとなんだけどなぁ……と思いつつも,結局,条件が揃えば発現するという状況は避けられないわけで,長い論理行が含まれる巨大ブロックを扱うときは,既存の[ESC]I などの巨大ブロック処理に依存しないマクロ(かなりローテクを極めそう)を制作するしかないのではないかと考えています。

 それでもなお,テンポラリファイルエラーの問題は付きまといますが……。

[4848] Re: 異なる現象の多重出現

としき 2022/07/02(Sat) 09:19
[4846]へのコメント http://toshiki.la.coocan.jp/
> ・テンポラリファイルエラー(昔からけっこうある)

昨日は宿直明け。
昼間、しっかり仮眠を取ったつもりだったんですがね。
夜、うっかり、板塀の生ログをいじってしまって。
バックアップ側を触っていると思っていたのですが、なんと本番ログ。
そして、よりによって保存のときにテンポラリファイルエラーが出てしまい、あっと思って確認したところ、ログ破壊判明。
すぐに復旧に取り掛かったのですがね。
バックアップのタイミングのせいで最新の発言がないので、単に書き戻すわけにも行かず。そして、古い発言にレスをつけたためにツリーの位置が変わっているので、どこにどの発言をどう戻すか、ということをあれやこれや。おまけに、実は半分眠いということを自覚したものだからそれだけ行動が慎重になり、トラブルの上乗せは避けられたけど、復旧までおおよそ1時間。
この復旧作業も、危険を承知でWinXPなサーバマシンのVzで行っていたんですが、一番重要なところは、やっぱりメモ帳。でも、メモ帳だとファイルの比較ができないので、チェックはVz必須。あと、ちょっとした書き換え、Vzで大丈夫かな、とやってみたときに、たぶん数年ぶりに見かけました、「ラインバッファがいっぱいです」というメッセージ。

> 中途段階のブロックエンドポインタが前の行末にずれることにより,行ブロックの挿入位置が1論理行ずれてしまう現象。

現象としてはそのように見受けられるのですがね。
これが、1バイトずれなのか1行ずれなのか、という部分で、私自身の考えが定まっていません。
あと、いまだに疑っているのが、根本原因は実はテンポラリエラーなんだけどVzの側でそれが検知できていないのではないか、ということ。

>  本来はこの現象の再現性を確認したいのに,その他のエラーも随時からんできて訳がわからない,調査が進まない,条件が確定しないというジレンマに陥っているわけですね。

まさにおっしゃるとおり。
発生確率が数百回に1回、とか言うのなら無視します。
でも、ほぼ確実に再現できる。
そのくせ、一見関係なさそうなBlとかを変えると、全く発現しない。

> 結局,条件が揃えば発現するという状況は避けられない

まぁそうなんですけどね。
最終的には、めざらさんご紹介のマクロを使うなり、本件に限っていえば、いくらでも回避策はあるのですが、ただ、やっぱり、文太さんのおっしゃるところの地雷、いまさら除去はできないのですが、どこにどんな地雷か、というところは確認したいものです。

[4847] Re^3: 再確認、失敗(0007.cgi 最小サイズ)

としき 2022/07/02(Sat) 09:19
[4845]へのコメント http://toshiki.la.coocan.jp/
>  ただ、僕はあれらの光景をほぼ見たことがありません。

それがいいことなのか悪いことなのか。
常に正常挿入、ということならいいことですが。
常に窓が落ちる、ということならこの上なく悪いことだし。
ただ、環境というよりもマシンによるものだと思いますが、私の場合、窓が自動で閉じるときも、画面がピカッと光った、ということは、どんなマシンでも経験というか記憶がありません。光らずに落ちる、というのは、時々経験しますけどね。

[4850] 行入れ替え再現できました

文太 2022/07/02(Sat) 16:23
[4845]へのコメント
 いちおうここにぶら下げます。


 元々、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が
固まっているのだと思う。)

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

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

[4851] 最後でだけ起こる?

文太 2022/07/02(Sat) 18:10
[4850]へのコメント
 結果だけ報告します。
 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が飛ぶ、ということになるように感じています。含まれる行の長さ
も関係してるのかなぁ。

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

[4852] 保守的になるための条件

文太 2022/07/02(Sat) 21:22
[4851]へのコメント
 まあ、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らしく
機械的でした。たとえ時にかたまるにせよ。

[4853] Re: 保守的になるための条件

文太 2022/07/02(Sat) 21:41
[4852]へのコメント
追伸

 大昔の話ですが、僕は結局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の反応はけっこう規則的でした。
ピンポイントに「ここから不具合が発現する」と特定はできませんでしたが。
 これが書きたかったのです。
 

[4856] Re: 保守的になるための条件

文太 2022/07/03(Sun) 01:07
[4852]へのコメント
各ファイルの最大論理長(エスキで挿入後)

 以下を使用して、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ぐらい?)で、ハングアップになるのですが。

[4854] Re: 行入れ替え再現できました

としき 2022/07/02(Sat) 23:42
[4850]へのコメント http://toshiki.la.coocan.jp/
>  おお、サイズが同じなのに、相違を出してくる。(つまり飛んでない!)

ごめんなさい、行き違いというか私のほうで勘違いが発生しそうなので、いくつか確認させてください。
飛んでいない、というのは、VzもしくはDOS窓のことですよね。
つまり、システムが飛んでいない、という意味ですよね。
あと、以前のお話では、システムが飛んでいないときはほぼ正常挿入だったということでしたが、今度は相違があるということですよね。すると、何を、またはどこを、変更されたのでしょうか。
これはもしかしたら非常に重要かもしれませんので、わかる範囲で結構ですから、ぜひとも情報提供をお願いしたい。
って、もうこの辺で既に私のほうに勘違いがあるかも。
#4845によると

> 僕はあれらの光景をほぼ見たことがありません。

ということでしたが、見たことがない理由というところを私が誤解しているのかもしれません。まず、ここからはっきりさせたほうがよさそうだな。
つまり、

・[ESC]Iを実行すると、ほぼ確実にシステムが飛んでしまうので、[ESC]I実行後のVzの画面を見たことがない
・[ESC]Iを実行すると、ほぼ確実に正常挿入の画面となってしまい、つまり複数の挿入終了パターンを見たことがない
・[ESC]Iを実行すると、ほぼ確実に異常挿入の画面となってしまい、つまり複数の挿入終了パターンを見たことがない
・[ESC]Iを実行したつもりになって、実は実行していなかった
・その他

といった解釈が私には可能です。
恐れ入りますが、差し支えなければ「見たことがない」理由を明確にご教示いただけますでしょうか。
何せ、異常挿入か正常挿入かはファイルの中身を分析するまでもなくファイル挿入終了時の画面を見るだけで判断ができるものですから、それを見たことがないということは、そこに何かがあると考えるのが妥当だと思われるのです。

恐れ入りますが、なにとぞよろしくお願いいたします。

[4855] Re^2: 行入れ替え再現できました

文太 2022/07/03(Sun) 00:09
[4854]へのコメント
としきさん

>飛んでいない、というのは、VzもしくはDOS窓のことですよね。
 さくっと、曖昧に返信

>つまり、システムが飛んでいない、という意味ですよね。
 です。はい、Vzが固まることはあっても、VTDOSが飛ぶということは
ありませんでした。

>あと、以前のお話では、システムが飛んでいないときはほぼ正常挿入だった
>ということでしたが、今度は相違があるということですよね。
 回答は曖昧です。僕が、ここで

>diff
blank!
 書いてきたときまで、きちんと正常挿入を確認をしていました。

 それ以後、「飛んだ」「不具合」というときは、「異常挿入」確認の手段が
そもそもありませんでした。つまり、としきさんのいう「異常挿入」は、僕の
環境では、結果ファイルが得られなかった、ということです。

 ファイルサイズだけでは「正常挿入」は確認できないと気づいたのはごく最近
です(あまり深い意味はありません。だって飛んでたのだもの)。ただ、#4842
あたりから、きっちり行番号・行長を調べ始めてます。
 飛びまくっていたのは、#4828 前後です。

>すると、何を、またはどこを、変更されたのでしょうか。
 全部(#4850から)を追試をしてもらったほうが早いでしょう。
 数字や長さは違うでしょうが、きっと、似た結果を得られると思います。
 #4828 以降、WinMEはまったく試していません。

 でも、僕はガチンコの原因究明は諦めています。
 いろんな原因が絡まってると(僕ごときから聞きたくないでしょうが)思って
います。純DOSレベルでも(Vz以前に)、起こるのじゃないのかなぁ。

[4857] Re^2: 行入れ替え再現できました

文太 2022/07/03(Sun) 11:37
[4854]へのコメント
としきさん

>あと、以前のお話では、システムが飛んでいないときはほぼ正常挿入だったということでしたが、今度は相違があるということですよね。すると、何を、またはどこを、変更されたのでしょうか。

 もう少しだけ丁寧な回答を試みます。

 今回の実験とそれまでの実験の何がいちばん大きく違うかといえば、対象のファイルサイズです。ご存知のとおり、不具合発現のファイルサイズ最小値を求めていたので、01.txt(1段落=1論理行のみが内容)から15.txt(1-15行が内容)程度です。ですから、おおかた不具合が出なかったのです。

 15.txt以降で発現し、16, 17, 18, 19, 20 あたりは、実験の初期段階でもう外されてましたから、Vzは固まる、VTDOSは飛ばない、程度で収まっていた、ということです。

 これに対して、としきさんご指摘の「冒頭17行でもう出る」0008.cgiとか0007.cgi全体とかを対象にすれば、それこそ、VTDOSが飛びまくっていてもおかしくはないでしょう。


>何せ、異常挿入か正常挿入かはファイルの中身を分析するまでもなくファイル挿入終了時の画面を見るだけで判断ができるものですから、それを見たことがないということは、

 繰り返しです。
 VTDOSが飛んだら、「ファイル挿入終了時の画面」は存在しないんですよ。ビカっと光るのです。瞬間的に窓が消失する。


 ここからは、あてにならない空想。

 ブロックポインタのずれだけでは、行入れ替え付きの「異常挿入」が起こる程度なのかな? だとすれば、Vzは落ちない。
 「ある一定の長さ以上の論理行」がVzが固まる条件? それもありうるけど、そうとだけとも言えない。反証はあった。しかし、16bitのsedも0007.cgiの論理行の長さに鳴きを入れてた。が、ちゃんと鳴けてシステム(VTDOS)を落とすことはなかった。しかし、Vzには、VTDOSを落とすことができる。
 ファイルサイズ。関係しているのでしょう。だとしたら、テンポラリーファイル?

[4858] Re^3: 行入れ替え再現できました

としき 2022/07/03(Sun) 19:50
[4857]へのコメント http://toshiki.la.coocan.jp/
文太さんに詳しく説明していただいたおかげで、やっと理解できました。
お手数をおかけしました。ありがとうございました。
この問題をみなさんに追試していただいた当初、めざらさんからは、テンポラリエラー発生の報告がありましたね。それと同様に、文太さんはめざらさん異常のシステムの問題があったというか、そもそもVzが異常をきたすだけでは済まず、Vzの下のレイヤごと落ちてしまう、という状況と理解しました。
この辺、めざらさんからも似たようなご指摘がありましたが、人によって、もしくは環境によって挙動が異なる、というのもいやらしいところだと思います。


>  ここからは、あてにならない空想。

文太さんの報告と併せて、私も空想。
まず、単純にファイルサイズだけが問題ではない。
もっと大きなファイルサイズで、全く問題は出ませんものね。
また、論理行の長さが関係する可能性は非常に高い。
そうだ、私、次の機会には、挿入する側される側の両方のファイルを、例えば72桁で桁折して、問題がないことを確認してみよう。それで問題が出るようなら、再び文字コードとかの問題に戻ってしまう。
また、論理行の長さの最大値の問題なのか、ある程度長い論理行の総量なのか、というところもどうなのか。
そしておそらく、最も根本的な問題は、Vzの扱える最大の論理行長の仕様が全くわからない、ということ。常識的に考えて、テキストバッファなりラインバッファを超える論理行を扱うのが難しそうだというのはわかりますが、今回はそういう値も越えていないはずで、何がなんだか。

[4860] Re^4: 行入れ替え再現できました

文太 2022/07/04(Mon) 12:51
[4858]へのコメント
としきさん

 熱中症がまだ完治しません。腰も頭も痛い、、、。

>再び文字コードとかの問題に戻ってしまう。
 はあ? あの掲示板ログにはVzが扱えないS-JIS以外の「文字」が入っている可能性ってあるんですか?
 秀丸って、S-JIS以外ではないと思うけど、「表現」できない文字があると、「そこ修正しますか?」と聞いてきます。たしかその問いは、このログではなかったと思うのだけど。

>何がなんだか。
 はい、何がなんだか、です。
 ただ、ふと先ほど、ある考えが浮かびました。
 行入れ替えの不具合と、(僕のように極端な場合)窓が落ちる不具合は、別問題なんじゃないか、ということ。
 前者がファイルの接合面で起こる(らしい)のは、かわいい不具合。
 しかし後者はまったくかわいくない不具合。僕の場合、たぶんかなりの高確率で16.txtで起きました。17-20.txtは、予測不能なぐらい不安定な結果を出してました。

 3つ目の場合、4つ目の原因とか、まだあるのかも。

[4861] Re^5: 行入れ替え再現できました

としき 2022/07/04(Mon) 17:20
[4860]へのコメント http://toshiki.la.coocan.jp/
>  はあ? あの掲示板ログにはVzが扱えないS-JIS以外の「文字」が入っている可能性ってあるんですか?

ありません。ないはずです。
でも、桁折したファイルでさえ挿入異常が発生するようなら、論理行長が原因の可能性が排除できるじゃないですか。そうすると、現時点で私が思い当たるものって文字コードしかなかったんですよ。

と、仮定の話をしていても仕方がないので、実験してみました。
0007.*の2ファイルとも72桁で桁折して、異常挿入は発生しませんでした。
よかった。
調子こいて、両方のファイルを2048桁で桁折した場合も正常挿入。
だけど、両方のファイルを4096桁で桁折した場合は異常挿入。
また、2048桁の.cgiファイルに4096桁の.cgファイルを挿入した場合は正常挿入。一方で、4096桁の.cgiファイルに2048桁の.cgファイルを挿入した場合は異常挿入。
ほうほう、なるほど。
やはり、支配的なのは、最初に開いていたほうのファイルみたい。

>  3つ目の場合、4つ目の原因とか、まだあるのかも。

あるでしょうね。高い確率で。
そして、それらがそろった場合に異常が発生する。
ただ、例えば4つの原因があって、AとBとCがそろうと異常挿入だけど、AとCとDがそろうとテンポラリファイルエラー、そしてBとCとDがそろうとメモリエラーで窓がシャットダウン、なんてことになっているような気がする。

[4862] Re^6: 行入れ替え再現できました

としき 2022/07/04(Mon) 17:52
[4861]へのコメント http://toshiki.la.coocan.jp/
> 調子こいて、両方のファイルを2048桁で桁折した場合も正常挿入。

> また、2048桁の.cgiファイルに4096桁の.cgファイルを挿入した場合は正常挿入。

古い記録を確認したら、#4840

> 上記のとおり、27932バイトのファイルで異常が発生しています。
> そこで、ためしに2048バイトで桁折してみました。
> でも、(中略)無事に?異常挿入。

なんですね。
ちょっとここ、追及するべきかな、と思って、いくつか実験。
結果、常用環境で、2048桁で桁折した0007.cgiに0007.cgを挿入する実験では、何回も試したけど、全て正常挿入。ところが、27981バイトの、私のところでは0010.cgiと呼称しているファイルを2048桁に桁折したファイルでは、何回も試して、全て異常挿入。
なんだこりゃ。
念のため、いつもの、Blだけ8192にしたオリジナル.defのVz1.60でも試したけど、やっぱり、2048な0007.cgiだと正常挿入。でも、2048な0010.cgiだと異常挿入。
これってあれですね、文太さんのところでもあったかとおもうのですが、小さいほうのファイルはダメだけど大きいほうのファイルなら大丈夫、みたいな感じの話。

謎が謎を呼ぶなぁ。

[4863] Re^6: 行入れ替え再現できました

文太 2022/07/05(Tue) 13:14
[4861]へのコメント
としきさん

 なるほど、なるほど、という話の展開です。先については何も分からないけど。
 被挿入ファイル(.cgi)の状態が「支配的」と。

 ただ、としきさんの「異常挿入」って、マクロ操作後すぐ分かるという判断基準ですよね。
 いちばん軽度の行入れ替えは、いちいち確認してませんよね。そして、この場合、Vzは死んでない。ま、業務運行をするなら、とりあえず再起動がお勧めな状態なのかもしれませんが。

 僕のところでの「異常」のパターンは、以下の4種類。
(1)行入れ替え
(2)としきさんのいう「異常挿入」(最近、僕はみてないけど、昔diffしてNot blank で、文字化けとかしてた場合)=Vz死なず。(化けた@の連続みたいなのは見たことがない)
(3)Vzが止まる(ESCで窓が飛ぶ)
(4)ピカっとVTDOSが飛ぶ。

 (1)と(2)の境界線ぐらいは、曖昧にでも、分かりたいな、ぐらいでしょうか。
 上の4パターンには、OS依存な部分もあるんでしょう。

[4864] Re^7: 行入れ替え再現できました

としき 2022/07/05(Tue) 23:59
[4863]へのコメント http://toshiki.la.coocan.jp/
>  いちばん軽度の行入れ替えは、いちいち確認してませんよね。

当初は、いちいち確認していましたけどね。
ファイル保存して比較、という形で。
#4609とかの、一番最初に報告した当時はそうでした。
今では、挿入後の画面表示が行入れ替えが起きたときの状況であれば、行入れ替えが起こったとみなしていますね。つまり、先般の画面キャプチャで言うところの図2と同じであれば同じ行入れ替えが起こったとみなす、ということ。
なので、図6のように、挿入終了後画面がいつもと異なる場合のみ、ファイルを保存して中を探索、と言う感じ。

> 業務運行をするなら、とりあえず再起動がお勧めな状態なのかもしれませんが。

そうなんですけどね。
いちいち再起動も面倒なんで、大抵は、そのままずっと突っ走っています。
おそらく、ごくまれに再現不可能な挙動が発生するのは、そのせいでしょう。
逆に言うと、そういう事象は本当にまれ。
挿入試験だけではなく、時にはテキストを読んだりvz.defを編集したり、.cgiファイルや.cgファイルを編集したり、vztower.defで遊んだりもしますが、そういう小さなファイルをいじっているときに原因不明(または原因明快)な不具合に遭遇したことは全くありません。

>  僕のところでの「異常」のパターンは、以下の4種類。

うん、ここですれ違っている。
私、行入れ替えが発生することも「異常挿入」と称しています。
だって、正常じゃないから。
そして、ピカッと光るということは、全く記憶にありません。
ここで注意喚起。
「全く記憶にない」であって「全く経験にない」ではありません。



なお、後日きちんとまとめて報告しますが。
#4849の最後に.cgのファイルサイズを削ってどうなるか試すようなことを書いています。
これの実験を始めたのですがね。
通常のとしき常用環境、およびオリジナルVz1.60およびBlだけ書き換えたオリジナルvz.defのいずれでも発生する状況です。
過去の実験ではいずれも、挿入完了時、正常挿入だろうが異常挿入だろうが、カーソル位置は論理行頭にあります。ところが.cgファイルのサイズを削っていくと、挿入完了時、カーソルが1つ前の行の論理行末に存在して終了することがある。
おそらく、このことからもめざらさんご指摘のとおり、何らかの不具合発生の際に1バイトずれが発生しているということで間違いないでしょう。
この件、まとまったら報告したいけど、いつまとまるやら。

[4879] Re^8: 行入れ替え再現できました

としき 2022/07/11(Mon) 22:52
[4864]へのコメント http://toshiki.la.coocan.jp/
> #4849の最後に.cgのファイルサイズを削ってどうなるか試す

常用環境で試した結果です。
当初は製品版環境でも試そうとしていたのですが、なぜか製品版環境では異常挿入が起きなくなってしまいました。別発言に書きましたが、理由は不明です。

0007.cgを末尾のほうから削っていった場合、
32行目以降を切り捨てた0007.cgファイル(70727バイト)なら正常挿入
33行目以降を切り捨てた0007.cgファイル(73620バイト)だと1バイトずれ発生
以上、0007.cgiと0010.cgiいずれも同じ

0007.cgを頭のほうから削っていった場合、
24行目までを切り捨てた0007.cgファイル(72650バイト)なら正常挿入
23行目までを切り捨てた0007.cgファイル(75267バイト)だと異常挿入
以上、0007.cgiと0010.cgiいずれも同じ


もしかしたら行数を数え間違えているかもしれないので、ファイルサイズを明記しています。が、そうですか、73キロバイト前後ですか。
65536+8192がそれに近い数字になるのは果たして偶然でしょうか。

[4888] Re^9: 行入れ替え再現できました

としき 2022/07/27(Wed) 15:42
[4879]へのコメント http://toshiki.la.coocan.jp/
久しぶりに気力が戻ってきたので、続きをやろうとしているのですがね。
どうも何かおかしい。
#4879において、0007.cgi(170335バイト)および0010.cgi(27981バイト)のファイルを開いておいて、こちらは固定し、挿入する別のファイルのサイズを変化させた場合の結果を記しました。

> 0007.cgを末尾のほうから削っていった場合、
> 32行目以降を切り捨てた0007.cgファイル(70727バイト)なら正常挿入
> 33行目以降を切り捨てた0007.cgファイル(73620バイト)だと1バイトずれ発生

ところが、久しぶりに追試してみたところ、これが再現しない。
具体的にどうなったかというと

0007.cgiを開いていたとき、0007.cgを末尾のほうから削ったファイルで
33行目以降を切り捨てた0007.cgファイル(73620バイト)なら正常挿入
34行目以降を切り捨てた0007.cgファイル(75539バイト)だと1バイトずれ発生

0010.cgiを開いていたとき、0007.cgを末尾のほうから削ったファイルで
34行目以降を切り捨てた0007.cgファイル(75539バイト)なら正常挿入
35行目以降を切り捨てた0007.cgファイル(77436バイト)だと1バイトずれ発生

なお、異常挿入が発生する最小ファイルサイズに近いところまで削った27933バイトのファイルにおいては、0010.cgiと同じ結果となりました。

何が起こったのかはわかりません。
一つ考えられることは、#4864に書きましたが

> いちいち再起動も面倒なんで、大抵は、そのままずっと突っ走っています。
> おそらく、ごくまれに再現不可能な挙動が発生するのは、そのせいでしょう。

こいつに引っかかってしまった可能性があります。
今までは、常用環境でやっていることって、おなじく#4864に書いたとおり
なので、常用環境を再起動してみたのですがね。
上記の結果に変化なし。
つまり、#4879の結果そのものが、再起動せずに突っ走った結果の異常値でした、ということのようです。
大変お騒がせしました。

念のため、Vz1.60製品版の.comファイルとBl8192の.defファイルでも試してみましたが、上記の同じ結果が得られました。

さて。
製品版でも同じ結果なので、上記の結果はある程度信用できると思います。
すると今度は、0007.cgiと0010.cgiで挙動が異なる、ということになるわけです。
なるほど。


次に、0007.cgを頭から削っていった場合。
こちらも常用環境を再起動して試しました。結果。

0007.cgiを開いていたとき、0007.cgを頭から削ったファイルで
24行目までを切り捨てた0007.cgファイル(72650バイト)なら正常挿入
23行目までを切り捨てた0007.cgファイル(75267バイト)だと1バイトずれ

0010.cgiを開いていたとき、0007.cgを頭から削ったファイルで
5行目までを切り捨てた0007.cgファイル(116642バイト)なら正常挿入
4行目までを切り捨てた0007.cgファイル(119396バイト)だと1バイトずれ
27933バイトのファイルにおいても、0010.cgiと同じ結果

なんと。
そして、製品版.comでも追試。
結果、常用環境と全く同じ。
なんか、こっちはずいぶんと大きな差分が発生しました。
おおむね40キロバイト以上?
でも、0007.cgiと0010.cgiのサイズ差は150キロバイトぐらいあるんだよねぇ。



今後の方向。
現在、行単位で境界値を求めていますが、もうちょっと値を追い込んでバイト単位まで求めるかどうか。いや、0007.cgiと0010.cgiで値が同じなら、やってもかまわないというかぜひやりたいところですけどね。かなり値が異なるようなんで、いまひとつ気が乗らない。
そして、以前、konnoさんが試されたことですが、BtとBlの値を変化させて、ここまで追及してきたある種の極限値が変化するか否か。例えば、Blを1024変化させて正常挿入と異常挿入の境界が1024変化すれば、それはもう、ここが当たり、という考え方。ただ、これをやるからには、やっぱりバイト単位で境界値を求めておくべきなんだよなぁ。
ところでBlって、1バイト単位で変化させられるのでしょうか。それとも256バイト単位?
あるいは、1バイト単位で変化させても値が丸められてしまうとか。
この辺、めざらさんにお教えいただければ幸いです。

[4890] Re^10: 行入れ替え再現できました

文太 2022/07/27(Wed) 23:44
[4888]へのコメント
>ところでBlって、1バイト単位で変化させられるのでしょうか。それとも256バイト単位?

 あはははは。
 おもしろい! ざぶとん、1枚。

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

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

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

[4891] Bl 1byte 単位で指定できます

文太 2022/07/28(Thu) 15:02
[4888]へのコメント
2022/07/28  14:52     257 000.txt		;bl256
2022/07/28  14:54     261 000.txt		;bl260

 000.txtを「111111 ...」という内容で作る。
 bl256のときと、bl260のときの最大長行を求める=「ラインバッファ
がいっぱいです」まで「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

[4892] Blの指定可能な値について

めざら 2022/07/29(Fri) 18:13
[4888]へのコメント http://mezala.la.coocan.jp/
> ところでBlって、1バイト単位で変化させられるのでしょうか。それとも256バイト単位?
> あるいは、1バイト単位で変化させても値が丸められてしまうとか。

ソースが読めないので,どういう仕組みかどうかは置いておき,実際にどのように指定が可能か「実験」してみました。

製品版の com & def を VTDOS 環境において起動時オプションで Bl を指定。
vzibmj -bl○○○○ という具合。
その結果 Bl は任意の値で指定可能で,値は丸められない…と分かりました。
なお,副産物として以下のような結果も得ました。(指定値の上限的な)

bl 2048 / pq..148==$776A, pq..149==$7F6A
bl 4096 / pq..148==$776A, pq..149==$876A
bl 8192 / pq..148==$776A, pq..149==$976A
bl 3000 / pq..148==$776A, pq..149==$8322
bl 3001 / pq..148==$776A, pq..149==$8323
bl 9000 / pq..148==$776A, pq..149==$9A92
bl 12800 / pq..148==$776A, pq..149==$A96A
bl 14848 / pq..148==$776A, pq..149==$B16A
bl 25600 / pq..148==$776A, pq..149==$DB6A
bl 32000 / pq..148==$776A, pq..149==$F46A
bl 40000 メモリが足りません.
bl 34000 / pq..148==$776A, pq..149==$FC3A
bl 34200 / pq..148==$776A, pq..149==$FD02
bl 34300 / pq..148==$776A, pq..149==$FD66
bl 34400 / pq..148==$776A, pq..149==$FDCA
bl 34450 / pq..148==$776A, pq..149==$FDFC
bl 34452 / pq..148==$776A, pq..149==$FDFE
bl 34453 メモリが足りません.

512バイトの緩衝領域+2バイトを前方(最上位メモリ)に確保しさえすれば,大きなラインバッファの「確保」は可能。ただし,正常に使用可能かは不明。

[4893] Re: Blの指定可能な値について

としき 2022/07/31(Sun) 23:41
[4892]へのコメント http://toshiki.la.coocan.jp/
> 実際にどのように指定が可能か「実験」してみました。

めざらさんもご存知のなかったこと、わざわざ実験していただきありがとうございます。
そうですか、仕様として扱われている数字の範囲外でも、実は明示的なエラーは出さない上に、なんとなくそれっぽく動いてしまいそうなわけですね。
めざらさんの実験結果を眺めて、このツリーでの本題とは離れて、例えばBlに256よりも小さな値を指定したときにどうなるのか、ということが気になってしまいました。それこそ、256まで丸められるのか、それとも、例えば8とか16とか指定したときに、その数字で起動されてしまうのか。もちろん、実用には耐えないわけですが。

私のこれからの方針ですが、とりあえず、Blの値として8191と、う〜ん、6144ぐらいかな、それで試してみたいと思います。あと、暗黙の仕様外の値として、8193と16384も、うちの環境で可能であれば、どのような挿入状況になるのか試して見ます。

[4870] Re^6: 行入れ替え再現できました

としき 2022/07/07(Thu) 19:38
[4861]へのコメント http://toshiki.la.coocan.jp/
> やはり、支配的なのは、最初に開いていたほうのファイルみたい。

ということで、0007.cgiファイルのみを桁折して、桁折なしの0007.cgファイルを挿入するという実験を行った結果。
2266桁で桁折した場合には異常挿入は発生せず。
一方、2267桁で桁折した場合は異常挿入発生。
桁折したファイルのバイト数はいずれも170385バイトで同じ。ただし、桁折位置が違う行が5ヶ所ばかりあるだけ。

ほほう、興味深い。
この筋もまた、追及したくなってしまいました。

[4872] 0007.cgi, 最小桁

文太 2022/07/09(Sat) 16:55
[4870]へのコメント
 微妙に違うみたいです。

>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

 どっから来たのだろう?

[4873] Re: 0007.cgi, 最小桁

としき 2022/07/10(Sun) 00:09
[4872]へのコメント http://toshiki.la.coocan.jp/
>  微妙に違うみたいです。

こういう話が伺えると、なぜか無性にうれしい。なぜだろう。
原因が究明できるわけでもないのにね。

>  どっから来たのだろう?

whatコマンドってありませんかね?
あれば、例えば

C:\>what c:\bin\fold.exe

みたいなことができると思う。
うちの場合は、あろうことか、whatコマンドが死んでいる。
存在はしていたんですがね。

[4874] what is what.exe?

文太 2022/07/10(Sun) 13:05
[4873]へのコメント
>whatコマンドってありませんかね?
 うーん、ないみたいですよ。unix-like toolsにも、ascii のtoolsにも。
 ネットで調べてみたけど、virusです、みたいなのが……。

 ネットの検索途上で、以下のような記事が。昔、話題になっていたと思いますが。
https://atmarkit.itmedia.co.jp/ait/articles/1404/24/news144.html

 「MS-DOS 2.11のソースコードが含まれている。(中略)ソースコードが複数に分割されているので分かりづらいがMS-DOSカーネルだけでも2万行以上あるようだ。(中略)すでにアセンブリ言語での開発は限界を超えていると思われるが(鑑賞するのもつらいレベル)」
 というのが、面白かった。そうか、2万行か。Vzは?

 ああ、黒い本。
 アセンブラならああいう見栄えになるものなのだろうとは思うけど、Vzのソースみたい、と。

[4876] Re: what is what.exe?

としき 2022/07/10(Sun) 22:41
[4874]へのコメント http://toshiki.la.coocan.jp/
>  うーん、ないみたいですよ。unix-like toolsにも、ascii のtoolsにも。

ありませんか。
でしたら、中に著作権表示か何かが含まれていることを期待して、stringsコマンドで

C:\>strings fold.exe

とかやってみるくらい、でしょうか。

[4877] strings.exe

文太 2022/07/11(Mon) 00:34
[4876]へのコメント
としきさん

 多謝。さすがです。

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だったのですね。ということは、やはり2バイト文字の認識とか
無理なんだ(たしかアスキーものは、なんとか判別するらしかった)

 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ドス窓ではOKです。
 ふと思う。David MacKenzieさんは、きっと無償でこれを世界に提供した。そんな
方々をVillage Centerは、日本に紹介してた(Vz以前)。特殊で高い能力がみんなの
ために、という方向に向けられた時代は終わったのですね。マイクロソフトがイケナイ!
全部、金、金、金、金、金!!!

 冷静になって。
 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オプションが指定されていない
場合,全角文字および半角カタカナはこれを可読文字とは解釈しません.


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

[4880] Re: strings.exe

としき 2022/07/11(Mon) 23:22
[4877]へのコメント http://toshiki.la.coocan.jp/
> 特殊で高い能力がみんなのために、という方向に向けられた時代は終わったのですね。

なんか、オープンソースコミュニティの存在を故意に無視されているような表現になっているところは、いささかいかがなものかと思ってしまう部分もある今日この頃、みなさまいかがお過ごしでしょうか。
OSからブラウザ、メーラー、動画再生ソフト、データベース管理ソフトまで、今の世の中、多くのソフトが、それぞれ多くの人によって開発されている世の中です。もしかして文太さん、世の中のトレンドをご存知ないのでしょうか。
ある時代が終わった、という言い方をするのなら、それは一人の人が単一のソフトを、という時代は確かに終わったといってもいいでしょう。現代では様々なシステムが巨大化してしまい、とてもじゃありませんが、一人でソフトを作れる時代ではありません。そして

> マイクロソフトがイケナイ!

確かに、GitHubもマイクロソフトが買収しましたけどね。
とはいえ、マイクロソフトの動向とはあまり関係なく、多くの人がひとつのソフトを造る時代になっていたはず。伽藍とバザールのいずれも、1人では成し遂げられない。
さらに、開発者のコミュニティの傾向としては、マイクロソフトよりもアップルのほうが嫌われている模様。なぜなら

> 全部、金、金、金、金、金!!!

収益化するにあたってのハードルは、アップルが大きいらしい。
きちんと調べていませんが、有料のソフトを配布するに当たっての制限が、アップルだと馬鹿にならないらしい上に、無料ソフトの配布が実質的にできないのだとか。ほんとかなぁ。
確かに、すごいソフトを作っても、それが作者に還元できない世の中は間違っていると私も思う。
だけど、文太さんの認識、または表現は著しく正鵠を欠いていると思う。

[4881] Re: what is what.exe?

文太 2022/07/12(Tue) 23:35
[4874]へのコメント
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です。こっちがメインだけど、何かをアセンブルとかする気には
まったくなりません。あくまでテキスト処理用です。

[4883] Re^7: 行入れ替え再現できました

としき 2022/07/15(Fri) 19:46
[4870]へのコメント http://toshiki.la.coocan.jp/
> この筋もまた、追及したくなってしまいました。

製品版のvz.comと.defファイルで異常挿入が発生しなくなってしまったもので、追及する元気が著しく減退しておりました。
例によって私が悪かった、ということが判明したので、少し元気を取り戻しつつあります。
さて。

> 2266桁で桁折した場合には異常挿入は発生せず。
> 一方、2267桁で桁折した場合は異常挿入発生。
> 桁折したファイルのバイト数はいずれも170385バイトで同じ。ただし、桁折位置が違う行が5ヶ所ばかりあるだけ。

実際には、桁折位置が違う行が11ヶ所ありました。
そこで、2267桁で桁折したファイルの、2266桁と桁折位置が違う部分を上から順番に2266桁で桁折したファイルとあわせて見ました。
結果。
1ヶ所目をあわせても異常挿入。
続いて2ヶ所目もあわせたら正常挿入。
では、ということで、2ヶ所目はそのままにして1ヶ所目を元の2267桁で桁折した状態にしてみたのですが、やはり正常挿入。
犯人はここか?

逆に、2266桁で桁折したファイルの桁折位置が違う部分の1ヶ所目と2ヶ所目を2267桁で桁折してみたところ、異常挿入。こいつの1ヶ所目を2266桁で桁折してみたところ、やっぱり異常挿入。
なるほど、やっぱり犯人はここらしい。

上記の実験で言うところの2ヶ所目というのは先頭から大体18行目、行頭4バイトが「2632」で始まっている行です。
ということはすなわち、#4840で言及しているところの、異常挿入を起こす最小サイズのポイントを含む行、なわけです。
うむ、妖しさ満点。
上記の、異常挿入を起こす最小サイズとしては27932バイトなわけですが、元のファイルではその部分はちょうど2バイト文字の真ん中に当たります。なので、2バイト文字の区切りで1文字増やした27933バイトのファイル、これに0007.cgファイルを挿入しようとすると当然、異常挿入になります。この場合、ファイル末尾は「気」という文字です。
ところが、同様に0007.cgiファイルのこの行の「気」の文字の次に改行を入れたファイルを作り、このファイルを開きなおして0007.cgファイルを挿入しても、正常挿入。ところが、そこにさらにもう1バイト、何でもいいけど半角文字を追加して保存して開きなおし、0007.cgファイルを挿入しようとするとそれは見事に異常挿入。
不思議だ、なぜ2バイトずれる。

ということで、桁折の方面から迫った結果も、大体同じところにたどりついてしまったようですが、非常に微妙なずれが発生することも分かりました。
スキルの高い人なら、ここまで来ればもう1歩、というところなんでしょうが、私には山の頂が見えているのかいないのかすら不明。
次に追いかけてみるのは、やはり#4879の筋でしょう。

[4859] 不具合発現最小ファイルの見つけ方

文太 2022/07/03(Sun) 21:34
[4842]へのコメント
 ここにぶら下げます。

【うちの結論】
 僕のところでは(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


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

[4849] Re^4: 改行置換

としき 2022/07/02(Sat) 13:59
[4840]へのコメント http://toshiki.la.coocan.jp/
> 上記の、桁折した場合の異常挿入について、[ESC]Iのマクロにトレースを入れたりして、もうちょっと詳しく見ていきたいと思います。

見てみました。
さっぱりわかりません。
:Cのループの中でおかしくなっている、というところまではわかりました。
2つ窓を開いて正常挿入のときと異常挿入のときで比較すると、#Bを実行後のところから違いが生じます。
もし仮にソースを読むとしたら、やっぱり#Bのところなんでしょう。

とりあえず、この方向を攻めるのも一旦やめて、0007.cgのファイルサイズの方面の攻略に向かいます。

[4868] 再現しました

文太 2022/07/07(Thu) 15:48
[4840]へのコメント
>> 異常挿入を起こす0007.cgiの冒頭からの真の最小のファイルサイズ
>見つけました。
>27932バイトでは異常発生、27931バイトでは正常挿入。

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

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

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

[4826] Re^3: 実験は試みたけど

としき 2022/06/24(Fri) 12:05
[4814]へのコメント http://toshiki.la.coocan.jp/
> 最後、0010.cgiを長い順にソートしようとして

#4825に書いた、私の検索オプションの設定を修正し、長い順にソートした結果のファイルを開き、ファイル冒頭で0007.cgを挿入。結果、異常挿入。
ある意味当然かもしれませんが、一応、報告まで。

↑ このページの先頭