一括表示

> 　リクエスト。
> 　１　としきさんがいってる（多いな、これ）、ファイラ９番メニューから担当
> アプリの名前を割り出す法。
　
　某所のあれ？　アプリの名前を割り出すって話になってましたっけ？
　てっきり Quick Exec できればよいものだと思っていたけれど…。
　単純にファイルを Quick Exec に渡すなら簡単です。
　
= quickexe = by H_ear
#if 0
システムメニュー09番の設定でリストからファイルをオープン
（てゆーか，ファイラーコマンドにファイル名を渡しているだけ。）
#endif
* mad for vz!
1 ^\ "" ?. k=ks&1,
    &> pf[=r,               ;local_buf as pf
    #60 (r)?{ &m(6) >z }    ;read tag(架空のパス名は終了)
    &Sc(pa,fl+34)           ;keep filer_path
    mx+,
    #O #e "*" #m
    &Sc(fl+98,"*.*")        ;マスク戻し
    (fl..6)?{               ;ファイラーのトップでないなら実行
        (k)                 ;\[CR]／[CR] のイメージ
        ?#n                 ;大文字指定
        ?#m                 ;小文字指定
        (s==1)?#m           ;%!:入力窓スキップ指定なし
    }
    &01                     ;リスト(編集モード)に戻る
    &Sc(fl+34,pa)           ;パス戻し
 :z ; ---- exit ----
    pf],
    mx-, .

00: ; ---- buffer ----
    (5+$)."$(00,1)$[256]"
01: #[ (s)?>^
*
　
[Variables]
    k   ks&1
[Buffers]
    &00 as pf[256]
    pa  keep filer path
[History]
2005/05/26 0.10 初版
[Notes]
#60は架空ファイル名を受け付けない
　
　システムメニューの構造から考えると、次のアイテムへのポインタがあった
りするわけではないので、ヌルで区切られたアイテムをひとつひとつチェック
していく必要があると思います。そのうえで %! とか %^ などをスキップして
さらに引数も取り込んで…、泥臭い方法しか思いつかないなぁ…。

めざらさん、
> = quickexe = by H_ear
　ありがとうございます。

> 　某所のあれ？　アプリの名前を割り出すって話になってましたっけ？
　詳細は、としきさんが何か仰ることがあるかな…。いえ、「名前の割り出し」
は僕の勘違いでしょう。
　そうか、「タグファイルがあるとして」という話でしたね。ようやく、話が見
えてきた。

　それより、タグジャンプ（＃６０）のことを勉強させてもらいました。
　プロファイルを出して、うーん、とうなったのですが、
c:\AAA ->1AF -+0 -KY11
　なんて場合、1AF って、カーソル位置のバイトオフセット（１６進）のことで
すよね。そうか、そんなことができるんだ！　詳細は後日（できたら）。これ、
かなりうれしいかも。つまり、タグジャンプって行でなく、タグさえちゃんと教
えてたら、桁まで正確に飛べるんですね。す、すごい。こ、こわい（何を今さら）。

> c:\AAA ->1AF -+0 -KY11
> 　なんて場合、1AF って、カーソル位置のバイトオフセット（１６進）のことで
　
　ロングポインタなので，オフセットではないですね。32ビットです。ただ，
VZ が編集できるファイルの上限が 16MB なので， 2GB までのポインタに対応
しているかどうかは実験してみたことがないので不明です。一応リードオンリ
のファイルならサイズ制限はないと言っても，そんなファイルを作ること自体
が無意味で。

めざらさん、ご指摘、多謝。実験してたら、ち、違うみたいだ…、と。

> 　ロングポインタなので，オフセットではないですね。32ビットです。

　なんですが、これ、久しぶりのカコログをグレップしてみたのですが、まった
くわかりませんでした。

c:\AAA ->1AF

　の  1AF って、１０進数に直せる数値ではないのですか？　まったく分かって
ません、すいません。宜しければ、お教えいただけますか？　431dだと思ったの
ですが…。

　FAQの以下のどれかに収まるべき話では、と想像しているのですが…。

> 再表示時のカーソル位置を任意に指定するには 
> カーソル位置の数値を取得するには 
> カーソル位置の十六進数値を取得するには 
> カーソル位置の二進数値を取得するには 
> カーソル位置の16ビットに納まらない数値を取得するには 
> カーソル位置の絶対番地を取得するには 

　いえ、急いでおりませんから、いつまででも待てます。といいつつリクエスト。

> 再表示時のカーソル位置を任意に指定するには 
> カーソル位置の絶対番地を取得するには 

　このどっちかでした。あとは数値の取得でした--&n, &h。
　失礼しました。

　めざらさん、３連発になってしまった。すいません。

　ああ、何だか慌ててるみたいで（疲れきってはいますが、別に急いではいない
のですが…）、たびたびすいません。

　黒本p.84を見ました（昨晩も見たんですが(^^;）。

->XXXXX   カーソル位置のポインタ（X:16進数）

　とありました。このポインタってどういう意味なんでしょう？　そして僕がそ
もそも持ち出してきた「バイト・オフセット」って？

　うん、 話を簡略に具体化させていただくと、GNU 系のグレップ（MS-DOS 用以
外のグレップ）って、どうもタグジャンプのやり方が違うのじゃないか、と思っ
ています。-t  みたいな「ファイル名：行番号」ってオプションがないみたい。
代わりに -b（バイトオフセット）というのがある。そこで、yagrep のことが頭
にあるのですが、マクロでファイル名を付加してやり（単一ファイル対象だとこ
れを出すオプションはグレップにはない） 、そのバイトオフセット（10->16 進
変換しなくちゃいけない）を使えば、桁まで正確にタグジャンプできるのじゃな
いか、と思ったのですね。外れてますでしょうか？　（変なこと訊かれても困る
かもしれませんが）この「バイトオフセット出力」って、そういうためにあるん
じゃないんですかねぇ、 というか、 そうなんじゃないかな、と思ったのです。
（emacs とかにタグジャンプがないわけじゃないだろうと思うのだけど…。）

　追伸：MS-DOS用以外のグレップに「タグ出力」がない。MS-DOS用にも（たとえば、
cgrep）「バイトオフセット出力」はある。が正確でした。

> 　とありました。このポインタってどういう意味なんでしょう？　そして僕がそ
> もそも持ち出してきた「バイト・オフセット」って？

　あれ，こっちに書くべきだったかな。
　「ポインタ」ってのは難しいですよね。なんだか色々意味が錯綜して，いよ
いよ分からなくなってきました。この件は，としきさんにタッチしたいなぁ。


　GNU 系 grep がバイトオフセット出力ってのは凄いですね。行なんて中途半
端なものじゃなく，ポインタでばっちり。すごいなぁ。

　要するに出力された十進数を十六進数に変換してやればいいわけ？ かしら

> いよ分からなくなってきました。この件は，としきさんにタッチしたいなぁ。

は？
私に何を期待しているのでしょうか？（笑）

> 　要するに出力された十進数を十六進数に変換してやればいいわけ？ かしら

とりあえず、用語の問題は別にして、例えば、バイトオフセットを出力してくる
grepを使って、Ｖｚのmac16.docからJkという文字列を検索すると、どのような
出力が得られるのでしょうか。それを見れば、めざらさんなら何をどうすればよ
いのかわかるのではないかと。


で、用語の問題。
ポインタって、ポイントするものだから、位置を指し示しているわけですよね。
この場合、通常、起点を０としたバイト数で指し示すことが多いような気がしま
す。で、オフセットっていうのも、ある位置からのズレ、みたいな意味がありま
せんでしたっけ。自動車の衝突安全性試験の一つにオフセット衝突試験ていうの
がありますが、あれも、正面衝突ではなく斜めからの衝突の試験だったような。
 

34109:&Jk(c)		２バイト文字の先頭文字の判断		(1)
C:\VZ\DOC\MAC16.DOC ->853D					(2)
&Fi		Init　pool	選択された最初のファイルへ	(3)
　　　　　　　　　　　　　　　　　　　　^ここへ？

(1)　cgrep　-b　"Jk"　C:\VZ\DOC\MAC16.DOC　の結果
(2)　34109は、１０進数だろうから１６進数にエスカルゴで変換後、タグ作成
(3)　飛んでみたら、はて？

　＞としきさん、よろしかったら、お教えいただけませんか？　やりたいことは、
たぶん、すでに見えていると思いますので？

　うーん、オフセット、そういう意味。分かったような気がする。offsetだもの
ねえ。確かにセットされてるところからずれてる。MS-DOSって、変な風にメモリ
を切って数えるでしたよね。

　みんな、ゆっくり楽しもう！　おい！

--test.txt--
あいうえおかきくけこ
さしすせそたちつてと
------------

>yagrep -o -b "さ" test.txt
22:さ
>yagrep -o -b "と" test.txt
22:と

　って、ことでヒット位置まで正確にタグジャンプというのは駄目なのかな？
　やっぱり。なんとなく、違う結果が出たことがあるような気がしたことがあっ
たように思ったのだけど。しおしおのパー。

　どうやら、マッチした行の先頭のオフセットみたいですね。
　目論見が外れちゃったなぁ〜。

なんか、結果を見ると、見つかった文字列を含む行頭のポインタを出力している
ッポイですね。であれば、

> 　って、ことでヒット位置まで正確にタグジャンプというのは駄目なのかな？

ダメ、ということになってしまいますので、とりあえず、検証していただけない
でしょうか。今回の例でいうと、検索語が「あ」でも「い」でも「こ」でも同じ
値になるか、みたいなことで十分だと思いますが。
 

 　としきさん、駄目でしたぁ。ああ、ぬか喜び。ああ、残念。やはりヒット箇所
でなく、ヒット行の先頭。

--test.txt--
あいうえおかきくけこ
さしすせそたちつてと
------------

>yagrep -o -b "あ" test.txt
0:あ
>yagrep -o -b "こ" test.txt
0:こ
>yagrep -o -b "さ" test.txt
22:さ
>yagrep -o -b "と" test.txt
22:と

まず、Ｖｚの行番号モードを表示行モードではなく論理行モードにします。
このときの、「Jk」という文字列の存在する行番号を取得します。
次に、今回得られた謎の数値「34109」に、その行番号の値を加算します。
加算の結果得られた数値を１６進変換します。
その値を使って

> C:\VZ\DOC\MAC16.DOC ->????

とやってみましょう。果たしてカーソルはどこにあるでしょうか。
 

> 果たしてカーソルはどこにあるでしょうか。

　恐いなぁ、実験してないけど。
　^@^@^@^@^@^@^@^@^@^@^@^@みたいなところに飛んでるとか。 

> 　恐いなぁ、実験してないけど。
> 　^@^@^@^@^@^@^@^@^@^@^@^@みたいなところに飛んでるとか。 

あのう、もしもし。
ファイルというかバッファが壊れていなければ、カーソルはEOFより後ろには
行かないような気が・・・
 

あはあは、実験しないで予想第二弾。
65536で丸められて割った余りの行へ飛ぶ。d(^o^☆＼(--#)実験しなはれ

> 65536で丸められて割った余りの行へ飛ぶ。d(^o^☆＼(--#)実験しなはれ

う〜ん、FFFFを超えるとありうるかも知らんけど。
MAC16.DOCを６０個くらい連結して試してみるとか。（ぉぃ）
 

mac16.doc ->890E
で、Jkの上。

・・・あれ？
えーと、何をやろうとしてたんでしたっけ。(^^;

#もはやチャット状態

> まず、Ｖｚの行番号モードを表示行モードではなく論理行モードにします。
> このときの、「Jk」という文字列の存在する行番号を取得します。
> 次に、今回得られた謎の数値「34109」に、その行番号の値を加算します。
> 加算の結果得られた数値を１６進変換します。
> その値を使って

977+34109=35086(890Eh)
C:\VZ\DOC\MAC16.DOC ->890E

　きゃあー、何これ？！！　バイトオフセット（１０進）＋行番号（１０進）、
これの１６進表記で、みごとに飛んだ。ど、どういうこと？

残業してます。(;_;)
ちょっと神奈川方面で大きな故障が出てしまって、帰りそびれてしまいました。

> これの１６進表記で、みごとに飛んだ。ど、どういうこと？

つまり、改行の数だけずれが生じているのですよ。
なんか、そのgrep、改行の扱いでバグというか独特な仕様となっているのかも
しれません。わかる人に調べてもらった方がいいかもしれません。
 

う〜む、改行を１バイトで数えているんですかね。バグっぽいなぁ。
何のマジックかと思いましたが、これって有名な話なんですか？

> う〜む、改行を１バイトで数えているんですかね。バグっぽいなぁ。

ですね。もとがUNIX由来のソフトですからねぇ。
例えば、nkfだったかな、改行が変換できるソフトがあると思いますが、
そういうのを使って改行コードが１バイトのテキストを作って、それを
最近のgrepで検索して、得られたオフセット値を使ってＶｚでジャンプ
した場合、きちんと希望通りのところに飛んでいくのでしょうかね。
非常に興味のあるところです。
もしかしたら、Ｖｚの側にバグがあったりして。


> 何のマジックかと思いましたが、これって有名な話なんですか？

「これ」というのがなにを指しているのかがちょっと読み取れませんが。
最近のgrepについての動きというのは、ここ数日のこの掲示板に書かれて
いる以上のことは知りませんし、自分で入手して実験してみたわけでも
ありません。生ＤＯＳでは動かなそうな処理系のような気もするし。
なので、もしかしたら有名なのかもしれませんが、私は存じていません。
って、そういう話ではないのかな。
 

> もしかしたら、Ｖｚの側にバグがあったりして。

　値を調整したらぴたり飛んだわけですから，大丈夫なんでしょう。

> 「これ」というのがなにを指しているのかがちょっと読み取れませんが。

　改行を 1 バイトで数えるバグを持つ grep があるってことです。
　状況をちょっと聞いただけで， UNIX 系ツールだから改行分のずれかもしれ
ないと推理したわけですから， UNIX 系ツールってその手のバグが入りやすい
ということが有名な話なのかな，と想像したわけです。

> 　改行を 1 バイトで数えるバグを持つ grep があるってことです。
> 　状況をちょっと聞いただけで， UNIX 系ツールだから改行分のずれかもしれ
> ないと推理したわけですから， UNIX 系ツールってその手のバグが入りやすい
> ということが有名な話なのかな，と想像したわけです。

あ、なるほど。でも、そういうバグって、いかにも仕込みそうなのに、あまり
話を聞かないですから、やっぱりそんなにないんじゃないでしょうか。

実は今回、まず最初に、値がいくつであれば正しいところに飛ぶのか、という
のをチェックしたのですよ。次に、文太さんが提示してきた値との差を求めた
のです。ここで求まった値が、さて何を意味しているのだろうとふとＶｚのス
テータスラインを見たときに、このときは表示行モードだったので値が一致し
ていなかったのですね。これが同じであれば行数の関係なんだろうな、と思い
ながらも、あれ、待てよ、となって、行番号モードを変えてみたらどんぴしゃ
だった、ということだったのでした。
 

> 実は今回、まず最初に、値がいくつであれば正しいところに飛ぶのか、という
> のをチェックしたのですよ。次に、文太さんが提示してきた値との差を求めた

　あ，逆算してたのですね。(^^;　参った。
　普通なら表示行で値が合わないところで諦めるところでしょうね。

めざらさん、以下をご参考に。（GNU grepのオプションです。yagrepの元。）

 -b
Print the byte offset within the input file before each line of output.
When grep runs on ms-dos or MS-Windows, the printed byte offsets
depend on whether the -u option is used; see below.

 -u
Report Unix-style byte offsets.  This switch causes grep to report byte
offsets as if the file were Unix style text file, i.e., the byte offsets
ignore the CR characters which were stripped.  This will produce results
identical to running grep on a Unix machine.  This option has no effect 
unless -b option is also used; it has no effect on platforms other than 
ms-dos and MS-Windows.

　UNIX系のGNU grepはWindowsやMS-DOSに移植されることを前提にしたオプション
が用意されている、ということですね。「よくある話」ではあるのでしょう、原
理的には。

　因みに、今回の経緯を正確に記すと、としきさんはある種の勘が働いたのです。
ただ、 それが cgrep という MS-DOS で開発された grep で起こったようだ、と
いうところで「その grep」という呼び方と、躊躇（ワトソンくん、何か間違え
てテストしてないかい？　とか）が生じたということです。 僕は、上を一昨日
読んでいたのに勘がぜんぜんまったく働かなかった。

　伝言ゲーム的な要素があるので、１００％の自信をもって伝えられるわけでは
ないのですが、Bruce.  さんによると、以下の手続きは、Ｃのプログラムでは標
準的な手続きで、MS-DOS のソフトでも、CR をまずとってから本当の手続きに入
るものなのだそうです。 なので、cgrep -b の話は、いかにもやってしまいそう
なエンバグとのことでした。

> the CR characters which were stripped

　もっとも、 16 ビットの開発環境がない、ということで、cgrep 全般（？）に
ついてのバグ取りはできません、とのことでした。すると、準 MS-DOS でバイト
オフセットの出せるのは、古い GNU grep のマルチバイト版だけ、ということに
なりますね。もっともそうそう使う場面があるオプションでもないように思うの
で、ま、仕方なし、としましょうね。

> で、ま、仕方なし、としましょうね。

　まぁ，元々 grep にバイトオフセットを期待してないですしね。
　飛べたら，おー凄い，と思うかもしれませんが，宝探しじゃないので。

としきさん、こんにちは。

> つまり、改行の数だけずれが生じているのですよ。

　行番号って、改行個ぶんって意味かあ。納得。まるでシャーロック・ホームズ
みたいだ。

> なんか、そのgrep、改行の扱いでバグというか独特な仕様となっているのかも
> しれません。わかる人に調べてもらった方がいいかもしれません。

　「そのgrep」というのがいいですね。そうです。謎の数字を出したのはyagrep
ではなく、cgrepです。僕の手元には都合３種類のcgrepがあるのですが（オリジ
ナル、Bruce.特製ディレクトリ再帰オプション付き版、３２ビット版）、どれも
同じ。
　GNU  grep  2.3  でもyagrepと同じ結果（改行を２バイトと数える）なので、
cgrepのオリジナルからの、 誰にも気づかれなかったバグでしょう（バグと言っ
てよいのでしょうね）。さて、どうしよう？　いちおう、Bruce.さんにだけ報告
するか…？？？

> 私に何を期待しているのでしょうか？（笑）

　だって、この界隈でまともに普通のプログラムが組める人って、としきさん
くらいですから、オフセットとかポインタとかの概念を説明してもらえるんじ
ゃないかな〜と思いましてね。

　でも、なにやら雲行きが怪しいって言うか、GNU系grep の出力してくるバイ
トオフセットの指す番地が、マッチした文字列のある行の先頭ポインタみたい
なので、目論見が外れていきそうなんですね。

> で、用語の問題。

　ありがとうございます。イメージとしては自分の中にあるものとさして変わ
らないように思うのですが、たとえばあるハンドルでオープンされているひと
かたまりのメモリ上の存在（ファイル）とか、あるプログラムによって占有さ
れたひとかたまりのメモリ（データ）とか、あるいはプログラム自身が支配し
ているひとかたまりのメモリ（コード？）の先頭を「基点」として数えた番地
やら、そのメモリ内部の特定番地を「起点」とする相対番地やらが錯綜して、
説明に困っちゃってるんですよね。

めざらさん、色々と変なことを文脈ずらして言い出す奴ですいません。

> 　GNU 系 grep がバイトオフセット出力ってのは凄いですね。行なんて中途半
> 端なものじゃなく，ポインタでばっちり。すごいなぁ。

　手元のグレップ（cgrep,  ygrep, izgrep, dgrep）のドックを調べたところ、
やっぱり、 cgrep が少々特殊で、MS-DOS 用に開発されたグレップには「バイト
オフセット出力」はないのが普通みたいですね。でも、後ろ３つには「タグ出力」
がありました。相補的な関係になっているみたい。
　ただ、ポインタとオフセットについての語感に関しては、後者は分からないの
ですが、だいぶ違うみたい。ポインタって、ある基準を決めたときに相対的に決
まる場所、みたいな感じがしています。どうなんでしょうね。でも、言葉の定義
が問題ではありませんでした。これって、文脈抜きだと意味なさないでしょうか
ら。（でも、バイトオフセットをグーグルしてみるべきだな。）

> 　要するに出力された十進数を十六進数に変換してやればいいわけ？ かしら

　ま、こういうことになりそうですが、これが実験で、あれ、違う、となったの
で、困ってしまって…。あと、その変換には、awkを使うしかなくて…。

　僕の課題は、バイトオフセットを出力するグレップからのタグジャンプ、なわ
けですが、ちょっと色々調べてみますね。「タグジャンプ」なる概念がMS-DOSの
外でも通じるのかしら、と思っています。ＴＳＭＬで訊いてみちゃおう。

　あ、めざらさんのところの掲示板って、ishは大丈夫なんですか。としきさんも
再び（！）こけていた、インターネットでのishの扱いというのがちっとも分かっ
てなくて。いちおう、僕のところでは、正常にquick_exec動きましたけどね。？

> めざらさん、色々と変なことを文脈ずらして言い出す奴ですいません。

　わたしのコメントが重複錯綜して輪をかけているみたいですね。（笑）

> 　あ、めざらさんのところの掲示板って、ishは大丈夫なんですか。としきさんも

　HTML 4.01 としては、半角仮名は許容されています。
　…と言うか半角カナを含むShift_JISのようなコード体系を使用すれば、
問題はないはずです。ただ、掲示板CGIがどのような扱いをするかです。
これは ThinkPadが逝ってしまっているので、今は確認できません。実験
してみればよいのですが、どの段階でどう扱われるのかは不明です。
- - - - - - ▼半角仮名です - - - - -
アイウエオカキクケコサシスセソタチツテト
- - - - - - ▲ここまで - - - - - - -

> 再び（！）こけていた、インターネットでのishの扱いというのがちっとも分かっ

　従来インターネットメールサーバーで扱ってきたコードが ISO-2022-JPで、
これには半角仮名が定義されていません。それで、日本のメールサーバーでも
影響を考慮して全角に変換してしまうところが多いようですね。

　なので、ISH の符号化に半角仮名を使わないオプション sn とか s7 を使え
ば、掲示板はもちろん、メールであっても全く問題がないはずです。

　なお、「強制改行」で書き込むとおそらく右端がちょっとずつ折られます。

> てなくて。いちおう、僕のところでは、正常にquick_exec動きましたけどね。？

　としきさんのシスメニュ９番を甘く見てはいけません。DOS で使える聞いた
こともないようなマルチメディアフォーマットのローダーやら、各種のアップ
データの拡張子が、マクロバッファを半分くらい占めているのです、きっと。

お、やっぱり全角に変換されたよ。（笑）

> 　としきさんのシスメニュ９番を甘く見てはいけません。DOS で使える聞いた
> こともないようなマルチメディアフォーマットのローダーやら、各種のアップ
> データの拡張子が、マクロバッファを半分くらい占めているのです、きっと。

えと、一応、私のサイトのほうで、ちょっと古いバージョンではありますが、
VZ.DEFとVZFL.DEFは公開していたりします。笑ってやってください。
 

> 笑ってやってください。

　笑うのを通り越して、もはや唖然とするしかありません。(^_^;

　母艦もDOSなんですか？？？

> 　母艦もDOSなんですか？？？

です。
未だにPC-9821とDOS6と30BIOSなんてものを愛用しています。
ちょっと今は確認できないんですが、登録拡張子としては、確かWEBに公開
しているものに、WSPなんかが付け加わっているはずです。

めざらさん、こんにちは。

> 　半角仮名を使わないオプション sn とか s7 を使えば、

　了解です。でも、今回使うあてがなくなっちゃったけど(ToT)

> 　としきさんのシスメニュ９番を甘く見てはいけません。

　た、確かに。

> c:\AAA ->1AF
> 
> 　の  1AF って、１０進数に直せる数値ではないのですか？　まったく分かって
> ません、すいません。宜しければ、お教えいただけますか？　431dだと思ったの
> ですが…。

　431d ？？　それは何？　ああ，1AFh の十進表現ね。分かってるんじゃあり
ませんか。用語の話でしょうか。そうだとしたら，わたしもあんまり自信はな
いので鋭く突っ込まないでくださいね。

　バイトオフセットって言うと， 例えば wa+146にフルパスがあるという場合
に使う，構造体などの先頭を 0としてそこから何バイト先とかいうときの道程
＝バイト数のことですよね。ワードオフセットという言い方があるかどうかは
知りませんが，ともかく相対的な距離を表現するときに使うのだと思っていま
す。

　一方で，ロングポインタって言うと，こちらは絶対的な数値，つまりファイ
ルで言えば先頭を 0として，そこからの距離と解釈できると思います。それじ
ゃただのポインタって何だぁ？？

　メモリの話になると，64KB をセグメントという単位として， そのセグメン
トの中の相対的な位置をオフセットと言いますね。

　IP アドレスみたいな場合は，192.64.200.0 というようにドットで区切られ
た位をセグメントと呼んでいるようです。

　う〜ん，書いているうちにだんだん自信がなくなっていくなぁ…(笑)

> = quickexe = by H_ear

これ、ちょっとだけ試して見たのですが、期待した動作をしません。
９番メニューに登録済の拡張子を持つ実在のファイルをテキストファイルに記載
し、その行の上で^\して見たのですが、瞬間的に画面がちらちらっとするだけで、
元のテキストに戻ってきてしまいます。
そこから[ESC]O[RET]でファイラーに行くと、このマクロ実行前は２画面ファイ
ラーだったのに片面だけとなっています。また、そのファイラー画面に表示され
ているファイルも該当のファイルだけで、あたかもマスクがかかったままになっ
ているような感じです。それにも関らず、ファイラー左上のマスク表示はきちん
と*.*になっていたりします。その状態から[*]を押すと、同一ディレクトリの中
の他のファイルが表示されるので、ますますマスクがかかったままの状態に近い
のではないかという気がします。

後で、製品付属のvzfl.defでの試験や、&tを用いたトレースなどを実施します。



いやぁ、たぶんこのあたりのことを４年前に知っていたら、当時からかっていた
browser.defがもうちょっとましなものになっていたんでしょうね。
 

> これ、ちょっとだけ試して見たのですが、期待した動作をしません。

　まぁ，そりゃそうでしょうね。シスメニュ９番なんて，ばきんばきんに環境
依存ですから。なんか変だったんでしょう。

　基本形なので，あとは環境に合わせてカスタマイズしてみて下さい。

> そこから[ESC]O[RET]でファイラーに行くと、このマクロ実行前は２画面ファイ
> ラーだったのに片面だけとなっています。また、そのファイラー画面に表示され

　さすがに起動時のパスは保存してありますけど，fg.0までは弄っていないで
すね。このあたりは好みですから。 [ESC]^ の外部マクロロードだって，実行
後の状況は似たようなものでしょう？

　マスクはちょっとまずいですね。でも，マスク戻しはしてるつもりなので，
再読込みフラグか何かを初期化しないといけなかったのかな。pq.-7-, とか。