軟式さんに許可をいただいたので、以下にテスト版URLと説明を載せます。

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

　テスト版を作成しました。下記よりダウンロードしてください。
　64bit 版実行ファイルのみです。
https://www.nanshiki.co.jp/test/dosboxj_test2.zip

　Vz のマクロから CLPPST.EXE を呼び出してコピー・ペーストできる事は
確認しています。

　mount したドライブ上でのみ使用可能です。imgmount したドライブ上の
ファイルはWindows からは見えませんので使用できません。
　また、mount c c:\ 等として Windows のドライブと DOSVAXJ3 上のドラ
イブ構造が同じとなるようにしてください。
　mount c c:\dos 等とすると Windows のコンソールプログラムから参照
するファイルと DOSVAXJ3 から参照するファイルのパスが異なってしまい
期待通りの動作をしなくなりますのでご注意ください。
　上記例の場合 Windows の C:\DOS\VZ に Vz 関連が入っているとして
C:\DOS\VZ\CLPPST.TMP .. Windows 上のファイルパス
C:\VZ\CLPPST.TMP     .. DOSVAXJ3 上のファイルパス
　と異なったパスになってしまいます。
　Windows コンソールプログラムに正しいファイルパスを渡せるようであ
れば問題はありません。
　またフルパスを指定せずカレントディレクトリのファイル名を渡すのも
問題ありません。例えば DOSVAXJ3 上で C:\VZ に移動し
C:\VZ> CLPPST /R CLPPST.TMP
　とした場合は Windows 上の C:\DOS\VZ\CLPPST.TMP を読み込むことがで
きます。
　おまけで Windows デスクトッププログラムも DOSVAXJ3 から起動できる
ようにしています。

　今回の目的としては clppst.exe 使用だと思いますので問題ないとは思
いますが、コンソールプログラムで文字入力があるものは使用できません
のでご注意ください。固まってしまうので、一定時間出力なしで強制終了
させています。

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

私は [autoexec] セクションに
mount c c:\
mount d d:\
こうしているので問題ないですが、確認しておいた方がいいですね。
VTDOSやMS-DOS Playerはデフォでドライブ丸ごとマウントしているだろうから同じ土俵に上がった感じですね。
本当にありがとうございました。

DOSVAXJ3 (2024/11/15)テスト版のメールをいただきました。
内容は

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

　さらに見直しまして、Visual C++ 製のプログラムであれば入力も可能とな
りました。clppst.exe は Delphi 製ですが入力はありませんので問題なく動
作します。

　途中で止まってしまうプログラムは Ctrl-C で強制終了できるようになりま
したのでタイムアウトによる終了はなくなりました。

　表示がでない Windows コンソールプログラムがありましたら
> set dosvaxj3=noinput
　とした後で実行してみてください。
> set dosvaxj3=setenv
　で現在設定されている環境変数を Windows コンソールプログラムに渡しま
す。PATH 等は上書きされます。ただし COMSPEC と DOSVAXJ3 は渡しません。
　両方設定する場合は set dosvaxj3=noinput,setenv となります。

　テスト版は下記にあります。
https://www.nanshiki.co.jp/test/dosboxj_test5.zip

　特に問題がなければ来週早々に正式版にする予定です。

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

ということでテスト版試してみました。
GREPなど入力系のプログラムが動くようになりました。ありがとうございます。
うれしいです。

gawk はリダイレクトでsyntax errorが出ましたが、リダイレクトしなければ動きました。

gawk "BEGIN{print mktime("""2004 09 28 20 57 00""")} >utime
gawk:                                                ^ syntax error

gawk "BEGIN{print mktime("""2004 09 28 20 57 00""")} 
1096372620

試した版は以下の日付のものです。
GAWK     EXE       446,464 05-12-23    0:24
GREP     EXE        96,256 09-02-13   17:19
YAGREP   EXE       233,472 09-03-31    2:28

grep.exe は、フォルダの再帰検索が安定しているので動いて嬉しいです。
GREP -Hnir "yagrep" *.*

yagrep.exe は、DCログの再帰検索で漏れが結構ありました。
Yagrep -r "yagrep" D:\log\fgal\DC\

この２つで比べてみてください。yagrep.exe の漏れは仕様かも。
テスト版の動作検証にご協力願います。m(__)m

> 　お久です。うーん、すっかりＰＣいじりの世界からは遠のいております。
> 　例によって、今日も超疲労モード。

文太さん、お久です。お元気そうで安心しました。

> 　さて、yagrep.exeですが、このようなテストには向かない道具かと思います。
> 　Bruce.さんが、onigsed, yagrep とも、正規表現エンジン鬼車を搭載して、
> GNU sed & grep を日本語対応させて移植してくれたものなのですが、詳細は
> 省かせていただきますが、僕はまったく使っていない、ないし使わないことに
> したツールです。限界などをみきわめられれば使えるところを使うことは可能
> なのかもしれませんが、ちょっと、、、。

私が使っている grep.exe は多分 GNU GREP だと思うんですが、yagrep は GNU系だったんですね。
今回のテストはあくまで DOSVAXJ3テスト版で動作するようになった32ビットの入力系コマンドの検証なので。
grep.exe などは今までは使えなかったのです。

> 　対象ファイルに漏れがでる、ということですよね。僕はこれを経験して
> いませんが、それ以外で、、、。うーん、考え方によってはヒットすべき
> ものがヒットしていないから、あたかもそのファイルが検索されていないかの
> ように見えることもあり得るのかな？

この掲示板の過去ログで話題にしているかと思い検索したら、yagrep の癖など全部話題に出ていましたね。
#8206
> XXXX.HTM 219593: 需要予測
> だけど、この、「需要予測」 が、Yagrep だと検索引っかからないんですよ。
> 「予」が、$975C なので、「￥」$5C と認識しているのかも。
>       --ctype=SJIS              force matching in Shift-JIS mode
> このオプションを付けてもダメだったような。
#8210
> >だけど、この、「需要予測」 が、Yagrep だと検索引っかからないんですよ。
> 　再現しました。

また MS-DOS player でも yagrep.exe は動かなかったんですが、それも
#7774 GREP の動作の違い
> MS-DOS Player + yagrep
> C:\VZ\K07T5>C:\UT\YAGREP.EXE "AF"
> 'C:\UT\YAGREP.EXE"  "AF' は、内部コマンドまたは外部コマンド、
> 操作可能なプログラムまたはバッチ ファイルとして認識されていません。

この時と同じメッセージなので、やはり３２ビットの入力系コマンド対応は難しいということなのかも。

> 　環境を試すツールがあれですと、環境かツールか？　と沼にはまりそうな
> 気がします。

環境とは DOSエミュのことですよね、その違いがツールの動作に影響することは確かにありそうですね。

konnoさん

C:\BIN>dir | grep -i "grep"
1994/06/02  18:50            90,959 EGREP.EXE
2003/04/14  00:00            80,412 FGREP.EXE
1994/06/02  18:50            90,959 GREP.EXE
1999/11/11  00:00            82,944 OGREP.EXE
2009/03/31  02:28           233,472 yagrep.exe
1994/04/30  10:07            66,700 YGREP.EXE
1993/04/11  16:05            23,997 IZGREP.EXE

　３２ビットアプリと１６ビットアプリ。上の３つは３２ビット
だったのではないのかな？

https://www.vector.co.jp/soft/dos/util/se008484.html?_ga=2.40740194.1106177368.1731818139-1020062094.1731818139
　これじゃないかな？

　で、本文に戻ります。

>文太さん、お久です。お元気そうで安心しました。
　基本的には元気で健康です。ただ今年はなんだかんだと忙しくて。
　あと４か月半！

>今回のテストはあくまで DOSVAXJ3テスト版で動作するようになった32ビットの
>入力系コマンドの検証なので。
　VTDOS以外のＤＯＳエミュレータを使ってないので、よくは分からないのですが、
もしそれらがほんとの【ＤＯＳ】（16bit）エミュレータなら、特別なことを
してくれてないと、３２ビットアプリは動かないのが道理ですね。でも、rcp32.exe
とかも？

>この時と同じメッセージなので、やはり３２ビットの入力系コマンド対応は難しい
>ということなのかも。
　VTDOSが「ほにゃららホストに丸投げしてます」とかで、32/64bit 環境も意識して
作られている、ということなのでしょうか。

>> 　環境を試すツールがあれですと、環境かツールか？　と沼にはまりそうな
>> 気がします。"
>環境とは DOSエミュのことですよね、

　はい、そのつもりです。考えてみたら、ＸＰのＤＯＳ窓もＤＯＳエミュでしたね。
　rcp32.exeもclppst.exeも、ふつうに動いていた。

　yagrep.exeがテストに向かないにせよ、一部動いた、みたいな結果だったのです
よね？　謎ですが。

>DOSVAXJ3テスト版で動作するようになった32ビットの入力系コマンド
　（繰り返しですが）yagrep.exe以外の３２ビット grep でのテストがよろしい
かと。

> C:\BIN>dir | grep -i "grep"

おお、パイプでこんなことが出来るんですね。勉強になりました。
てか、このパイプは VTDOS でしか使えないようですね。
DIR *grep*   		だと全ファイル表示してしまいますね。
tosfind.exe /n*grep*   	これは目的のファイルだけ表示してくれますが、下位フォルダまで表示してしまいますね。
mls.com /l *grep*	これも目的のファイルだけ表示してくれますが、DOSVAXJ3では何故か全ファイル表示してしまいます。
LS系は目的ファイルだけ表示するものと全ファイル表示するものが混在しているようです。
余談になりました。(^^;

> https://www.vector.co.jp/soft/dos/util/se008484.html?_ga=2.40740194.1106177368.1731818139-1020062094.1731818139
> 　これじゃないかな？

日付もサイズも全然違うので別物だと思います。いつどこで落としたのか思い出せないです。(^^;

> 　基本的には元気で健康です。ただ今年はなんだかんだと忙しくて。
> 　あと４か月半！

無理せず頑張ってください。

> もしそれらがほんとの【ＤＯＳ】（16bit）エミュレータなら、特別なことを
> してくれてないと、３２ビットアプリは動かないのが道理ですね。でも、rcp32.exe
> とかも？

かなり特別な処理をしてくれているようです。CLPPST.EXE がきっかけで対応してくれたのでありがたいです。
コピー系は ZCPY32.EXE が動くので rcp32.exe も大丈夫だと思います。

> 　VTDOSが「ほにゃららホストに丸投げしてます」とかで、32/64bit 環境も意識して
> 作られている、ということなのでしょうか。

結果的にパイプにも対応できているのは凄いことなんだなと改めて思いました。

> 　yagrep.exeがテストに向かないにせよ、一部動いた、みたいな結果だったのです
> よね？　謎ですが。

他のDOSエミュでも同じ結果のようなので、やはり yagrep.exe 自体の問題と思われます。

> 　（繰り返しですが）yagrep.exe以外の３２ビット grep でのテストがよろしい
> かと。

常用の grep が動いているのでおおむね問題なさそうだと思います。

konnoさん

C:\BIN>dir | grep -i "awk"
1993/09/25  05:51           188,444 JGAWK.EXE　　16bit
1998/08/22  22:01           142,759 MAWK32.EXE　　コレ
　　　　　　　　　　　　　　サイズからして日本語対応してなさそう

C:\BIN>dir | grep -i "sed"
1988/03/02  06:11            15,366 OLDSED.EXE　　16bit
1999/06/20  13:40            90,112 sed32.exe　　コレ
　　　　　　　　　　　　　　日本語対応してそう

　grepと同じことは、sed, awkでもできます。タイムスタンプとかファイル
サイズだけみて、上のリストはいい加減なことを言っている可能性が
あります。oldsed.exeとかは、serowさんの超古典の奴です。
　ベクタで探してみてください。

> 1993/09/25  05:51           188,444 JGAWK.EXE　　16bit
> 1998/08/22  22:01           142,759 MAWK32.EXE　　コレ
> 　　　　　　　　　　　　　　サイズからして日本語対応してなさそう

うちのawkは

JGAWK    EXE       188,444 93-09-25    5:51
MAWK32   EXE       193,536 98-08-22   23:02

こうなっていますが、いずれも日本語対応しています。
って、mawk32は、なんかすげぇ微妙なバージョンの差異があるかも。

> 　grepと同じことは、sed, awkでもできます。

御意。
単に専用ツールか多機能ツールかの違いだけ。
鶏を割くのに牛刀を使って何が悪い。

としきさん

　（以下すべて、VTDOS環境です）

　多謝。ベクタにありました。ソースもありました（???.tar.gzの展開の
仕方わすれたのだけど）。

C:\WK>dir

1997/11/01  11:02            44,369 mawk.doc
1998/08/22  22:02           193,536 mawk32.exe
1996/09/18  10:23             2,524 README
1998/08/22  21:59             6,390 README.SJ

----- t.txt -----
　まだ何か思いつくの？
　ディレクトリ再帰について。
-----------------

----- t.awk -----
/ディレクトリ/{
print}
-----------------

C:\WK>mawk32.exe -f t.awk t.txt
　ディレクトリ再帰について。

>って、mawk32は、なんかすげぇ微妙なバージョンの差異があるかも。

　ファイルサイズからして、僕のmawk32.exeは、日本語対応のない
英語圏から落とした奴だったんじゃないかな。
　タイムスタンプが、え、え、え？？？　という感じだったけど。
　無事、日本語対応 mawk32 がゲットできました。多謝。
　16bit の jgawk.exeしか、ほとんど使ったことないのだけど。


蛇足：

C:\WK>mawk32 -W version（新版）
mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan
  Adaptation for MBCS (P. yedoensis R27) by KIMURA Koichi


C:\WK>cd c:\bin

C:\BIN>mawk32 -W version（旧版）
　VTDOSがはじいて、「アプリケーションエラー」

　おめでとう！　きっと使わないけど、使える mawk32.exe だ！

konnoさん

　うーむ、どう回答したものやら？

　おそらく一番大事なのは、
>が、DOSVAXJ3 では何故か動かなかったです。
　でしょうか。

　これは、DOSVAXJ3の作者様に報告していただくしかないでしょう。
　僕は、VTDOS以外、ＤＯＳエミュレータを知らないんです。
　VTDOSをよく知っているわけでは、まったくありませんが。

　で、元にもどっていちおう整理を試みると、なぜwild.exeが登場したかと
いうと、yagrepで「ディレクトリ再帰」が変、とkonnoさんが仰っていたから
です。
　以下の表をみてください。16bit の grep で「ディレクトリ再帰」が
オプションで可能なのは、wgrep, ygrep, jgslimだけだそうです。

			cgrep	Ggrep	akgrep	wgrep	ygrep	izgrep	dgrep	jgslim	zf
directory下再帰					-u	-r			-a

　で、grep, sed, awk にも、ふつうその機能はないけれど（多くのフィルタ系
ツールも）、wild.exeをかませると、それが可能ですよ、と実用的なことを
話に僕がまぎれこませた、ということです。

　wild.exeは、ワイルドカード展開を助けてくれる、いわばメタツールで、
ですから

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

　の"head -7 $f >c:\wk\$x"の部分は、展開されるべきワイルドカードを
含んだコマンドなのです。
　コマンドの中身が、"head -7"（ファイルの冒頭７行を表示。８行目以降は
見せるな）で、$f がワイルドカード的に展開されるべき対象ファイル名です。
　（typeだと、冒頭７行だけ、というわけにはいかないでしょう？）

　$f, $x を Siさんは「マクロ」とドックで呼んでいたと思いますが、
wildの使い方は、wild.doc を読んでもらって試してもらうのがはやいです
（必要ないでしょうけれど。必要がなければ、けっこう難解です）。

　「ディレクトリ再帰」がないツールにその機能を付加する。これがwild.exe
のお仕事であり、ここで登場してもらった理由です。


　さらに元にもどって。
　DOSVAXJ3 のテスト。これがkonnoさんの主目的ですよね？
　だとしたら、まず、VTDOSと結果を比較するのがよいのではないでしょうか？
　意図的なのかもしれないけど、僭越ながら申し上げると、割と迷走モード
っぽいような印象を受けました。

　パイプにせよ、ワイルドカードの展開にせよ。
　もっとも、ワイルドカードの展開は、外部ツールでは、そいつがすることに
なっていたと思うけど。
　dir みたいな内部コマンドだと、さて誰が展開するのでしょう？　ですが。
　command.com? あるいは、ＤＯＳエミュレータ本体？

　上のくだりでは、僕自身が迷走してますが、ま、今の僕の課題ではないので、
ご容赦ください。


　大量に本を捨てている毎日ですが（仕事おさめ）、ＤＯＳ関係本はとって
あります！　fortranとpascal関係本は、うう、どうしよう？　ですが。
　とっとく！

追伸：「引用なし」ボタン。最高です。僕はこれを愛してます。

konnoさん

>作者様にメールしたんですが、その後に私の設定ミスが原因
　原因が判明してよかったですよね。
　やっぱり作者様に報告したのに、自分のミスだったというのは
格好が悪いかもしれませんが、良好な関係ができていたら、「ごめん、
こっちのミス」もありでしょう。というか、僕はそればっかの人生みたい。

>[autoexec] セクションで
>set COMSPEC=c:\ut\95\COMMAND.COM

　そ、そんなディレクトリがあるんですか？！　さすが。
　Win95系のツールとかも、ここに格納されていると。

>再帰というわけではなく、検索漏れが多かったのです。

#11645
>grep.exe は、フォルダの再帰検索が安定しているので動いて嬉しいです。
>GREP -Hnir "yagrep" *.*

>yagrep.exe は、DCログの再帰検索で漏れが結構ありました。
>Yagrep -r "yagrep" D:\log\fgal\DC\

　どっちにも、-r (recursive) がはいってますけど、、、。
　「再帰検索が安定」あるいは「漏れ」では、再帰に問題があると書かれて
いるように思われるのですが。

　細かくて、すみませぬ。

　ただ、現実的にいって、yagrep.exeには、いろんな問題があると思います。
　僕はＨＤから消してしまってもいいくらいの信頼感です。
　これだけ指摘したかったのです。
　もっとも、grep に Perl5 の正規表現は、僕ですら大して欲していなかった
と思う。

　たぶんkonnoさんがお使いのgrep(32)もＧＮＵのものでしょうから、「ＧＮＵ
による拡張」ですが、ちゃんと Perl5 の正規表現が使えます。

 -P
 --perl-regexp
 matching Perl regular expressions
Interpret the pattern as a Perl regular expression.

　ま、yagrepとonigsedについては、僕のような非力＆根性なし
テスターしかいなかった、というのが不幸の原因でした。konnoさんが、Bruce.
さんと一緒だったら、きっともっと完成度の高いものになっていたでしょう。

2009/03/31  02:28           233,472 yagrep.exe

　１５年まえ。僕がテスターをしたのは、これより２年前くらいだったのかな？

konnoさん

C:\>yagrep --help
（中略）
multi-byte extention:
      --ctype=ASCII             force matching in ASCII mode
      --ctype=EUC               force matching in EUC-JP mode
      --ctype=SJIS              force matching in Shift-JIS mode
      --ctype=UTF8              force matching in UTF-8 mode

　このオプションで明示的に SJIS mode でも、うーん、な結果だったと
思います。
　とにかく、僕的なポイントは、yagrepで何かをテストすると沼です、
これだけです。

>正規表現は使えれば便利ですが、私はほとんど使ってないので、通常検索で漏れの
>少ないものを選んだのです。

　こういう時は、grep.exe を 別ディレクトリにコピーの上、fgrep.exeに
リネームしましょう。正規表現が殺されます。すると、正規表現のメタ文字を
エスケープする手間が完全に省けます。意外にメタ文字に転んだりしてます。

> 　このオプションで明示的に SJIS mode でも、うーん、な結果だったと
> 思います。

過去ログでこのような話は見たような気がします。

> 　とにかく、僕的なポイントは、yagrepで何かをテストすると沼です、
> これだけです。

Parl5の正規表現と、GNUGREPの検索エンジンの相性か何かが悪いのかもですね。SJIS関連かも。

> 　こういう時は、grep.exe を 別ディレクトリにコピーの上、fgrep.exeに
> リネームしましょう。正規表現が殺されます。すると、正規表現のメタ文字を
> エスケープする手間が完全に省けます。意外にメタ文字に転んだりしてます。

えっ、GNU系GREPにはこんな機能があるのですか。早速 OMAKE.DEFに仕込んで DCフォルダで試してみました。
まずは今まで通りで
D:\LOG\FGAL\DC>GREP -nir "yagrep.exe" *.*
No files matching: *.*

FGREPに名前を変更すると
D:\LOG\FGAL\DC>FGREP -nir "yagrep.exe" *.*
13/bak/yagrep.log:107:YAGREP.exe -i -H -n "^v\.c\.\/salon" c:\lx\log\vzlog\mixvz\mixvz91\vz901003.log >mixxx
13/bak/yagrep.log:177:> YAGREP.exe -i -H -n "^v\.c\.\/salon" c:\lx\log\vzlog\mixvz\mixvz91\vz901003.log >mixxx

更に深い階層から見つけ出してくれました。＼(^^)／ ﾔｯﾀ-
これは良いですね、これからはこれで行きます。GREP も残しておいて比較してみます。
おいしい使い方を教えてくれてありがとうございます。

konnoさん

　konnoさんが試した結果については、うまく理解できませんでした。
　頭が働いてない。

grep では、"yagrep.exe"は、「.」が何でもあり（メタキャラ）、となり
fgrepでは、"yagrep.exe"は、「.」がピリオドと解釈されるはずです。

>GREP も残しておいて比較してみます。
　残しておきましょう。

　ＧＮＵ特有だったか思い出せませんが、grepは、

grep	のままだど、basic regex (sed 相当)
egrep	とリネームすると、extended regex (vwx 相当。awk 相当)
fgrep	とリネームすると、no regex となります。

　３つ、grep.exe, egrep.exe, fgrep.exe をＨＤＤに入れておいて
損はないと思います。
　とはいえ、grep １つでも、オプションで、egrep, fgrep 相当に
振る舞えたはずだとは思いますが。

　fgrep.exe を使いたいときは、けっこう特殊だと思う。
　egrep.exe を使いたいときは、「拡張正規表現使うからな」（メタ
キャラ、＋とか）と、思うと思う。

　３つ、c:\bin ディレクトリに入れておいて、損はないと思います。

konnoさん

　たぶん、こうなるのが正しいでしょう。

C:\WK>type t.txt (対象ファイルの中身)
yagrep.exe
yagrepxexe	;２行目は「.」でなく「x」

C:\WK>grep "yagrep.exe" t.txt（「.」はメタキャラ）
yagrep.exe
yagrepxexe	;両方ヒットする

C:\WK>fgrep "yagrep.exe" t.txt
yagrep.exe	;リテラルなのでピリオドだけヒットする

　grep.exe, egrep.exe, fgrep.exe は最近では廃止されて、かわりに
grep -E, grep -F を使え、ということらしいです。
　たぶん、古くからの UNIX的慣習で、egrep, fgrep へのリネーム技が
互換性の意味で、残されているみたいでした。


GREP(1)              UNIX Programmer's Manual             GREP(1)

       There  are three major variants of grep, controlled by the
       following options.
       -G     Interpret pattern as  a  basic  regular  expression
              (see below).  This is the default.
       -E     Interpret pattern as an extended regular expression
              (see below).
       -F     Interpret pattern as a list of fixed strings, sepa-
              rated by newlines, any of which is to be matched.
       In  addition,  two  variant  programs  egrep and fgrep are
       available.  Egrep  is  similiar  (but  not  identical)  to
       grep -E, and is compatible with the historical Unix egrep.
       Fgrep is the same as grep -F.

　とあります。うーん、"fixed strings"か。regexでない、という意味？
エンジンの動き方が違うのかな？
　質問されても、たぶん答えられないと思う。内容も英語も。

追記：fixed strings は「固定長文字列」と訳されていました。なるほど。
"a+" というパターンだと、ヒット文字列は、「a」も「aa」もありうる。
これは「固定長」ではないですね。

> 　たぶん、こうなるのが正しいでしょう。
> C:\WK>fgrep "yagrep.exe" t.txt
> yagrep.exe	;リテラルなのでピリオドだけヒットする

リテラルって直値という意味ですか？　こっちの方が意味不明です。
私の解釈では、正規表現無しなら全て単純な文字列として扱われると思ったし、結果も一致しています。

> 　grep.exe, egrep.exe, fgrep.exe は最近では廃止されて、かわりに
> grep -E, grep -F を使え、ということらしいです。
> 　たぶん、古くからの UNIX的慣習で、egrep, fgrep へのリネーム技が
> 互換性の意味で、残されているみたいでした。

なるほど。私のは2009年版なのでまだ古い方なのかもしれないですね。

separated by newlines

　自己レスです。

GREP
       -F     Interpret pattern as a list of fixed strings, sepa-
              rated by newlines, any of which is to be matched.

　タイトルの意味が分からなかったんですよね。

C:\WK>type t.txt
zzzzzzzzzzzz
yagrep.exe
yagrepxexe
zzzzzzzzzzzz

C:\WK>type t.grp
yagrep.exe
yagrepxexe

C:\WK>fgrep -f t.grp t.txt
yagrep.exe
yagrepxexe

　-f は、sed, awk などでも使う、スクリプトファイル指定のオプション
です。grep で、パターン【ファイル】を使うことは思いつきませんでした。
　パターンファイル内に、「改行くぎり」で複数パターンを書くことが
でき、「どれとでも」（any）マッチします。こういう意味でした。
　FGREPでは、正規表現抜きのオア検索になりますね。

> grep では、"yagrep.exe"は、「.」が何でもあり（メタキャラ）、となり
> fgrepでは、"yagrep.exe"は、「.」がピリオドと解釈されるはずです。

これはつまり、どちらでもヒットするはず、ということですか。
結果的には fgrep のほうだけヒットしたので、メタキャラの解釈にバグがあるかもしれないということ？
私的には検索漏れがあるのは駄目、ということで正規表現無しのほうが良いということになるのでした。

> 　ＧＮＵ特有だったか思い出せませんが、grepは、
> grep	のままだど、basic regex (sed 相当)
> egrep	とリネームすると、extended regex (vwx 相当。awk 相当)
> fgrep	とリネームすると、no regex となります。
> 　３つ、grep.exe, egrep.exe, fgrep.exe をＨＤＤに入れておいて
> 損はないと思います。

私の手持の GREP のZIPが32ギガのUSBメモリの中にありました。
grep-2.5.4-bin.zip
2018/10/06  00:36           451,824 grep-2.5.4-bin.zip
\bin\
2009/02/13  17:19            92,160 egrep.exe
2009/02/13  17:19            54,784 fgrep.exe
2009/02/13  17:19            96,256 grep.exe

機能別に3種の実行ファイルに分れているようです。
私は手軽に使い分けられるリネーム式でいきます。EGREP は使うことは無いと思います。

> 　とはいえ、grep １つでも、オプションで、egrep, fgrep 相当に
> 振る舞えたはずだとは思いますが。
オプションだと意味を忘れてしまうので。(^^;

konnoさん

　混線しています。

★
Bunta wrote:
>> grep では、"yagrep.exe"は、「.」が何でもあり（メタキャラ）、となり
>> fgrepでは、"yagrep.exe"は、「.」がピリオドと解釈されるはずです。

konno wrote:
>これはつまり、どちらでもヒットするはず、ということですか。
>結果的には fgrep のほうだけヒットしたので、メタキャラの解釈にバグがあるかもしれないということ？

　「これはつまり」がどこにどう繋がっているのか分かりません、すいません。
　konnoさんの２行目（「結果的には fgrep のほうだけヒットした」）は、

#11663 より引用

まずは今まで通りで
D:\LOG\FGAL\DC>GREP -nir "yagrep.exe" *.*
No files matching: *.*

FGREPに名前を変更すると
D:\LOG\FGAL\DC>FGREP -nir "yagrep.exe" *.*
3/bak/yagrep.log:107:YAGREP.exe -i -H -n "^v\.c\.\/salon" c:\lx\log\vzlog\mixvz\mixvz91\vz901003.log >mixxx
3/bak/yagrep.log:177:> YAGREP.exe -i -H -n "^v\.c\.\/salon" c:\lx\log\vzlog\mixvz\mixvz91\vz901003.log >mixxx

　に言及してますか？
　上のサンプル、もう少し整理していただけませんか？　よく読めないのです。

　-n: line number
　-i: ignorecase
　-r: recursive
　これらの意味は分かっています。が、何かが問題みたいに思えたら、この辺を整理する
のはどうでしょうか？


★のポイントに戻ると、
grep が "yagrep.exe" を検索パターンとするとき、「.」はメタキャラですから、ピリオドでも
何でもヒットします。

fgrep は、「.」に対し、ピリオドにしかヒットしません。正規表現抜きだから。リテラルと
解釈されるから。

　grep で結果が出ず（ヒットなし）、fgrepで結果が出る（ヒットあり）。何かおかしいようには
思われます。
　konnoさんが考えていること、というより、konnoさんがやっていることが、僕にはよく読めて
いないような感じがしています。

　ちゃんとしたツールで、「漏れ」とか、あってはいけないような気がします。
　僕の書くマクロじゃないんだし。

konnoさん、

　もう試されているかもしれませんが。

　以下を参考にしました。
-------------------------------------------
D:\LOG\FGAL\DC>GREP -nir "yagrep.exe" *.*
No files matching: *.*

D:\LOG\FGAL\DC>FGREP -nir "yagrep.exe" *.*
3/bak/yagrep.log:107:YAGREP.exe -i -H -n "^v\.c\.\/salon" c:\lx\log\vzlog\mixvz\mixvz91\vz901003.log >mixxx
3/bak/yagrep.log:177:> YAGREP.exe -i -H -n "^v\.c\.\/salon" c:\lx\log\vzlog\mixvz\mixvz91\vz901003.log >mixxx
-------------------------------------------


D:\LOG\FGAL\DC\3\BAK>GREP -i "yagrep.exe" yagrep.log
　これでどうなりますか？
　できたら、VTDOS と、その他のＤＯＳエミュで結果を比較してみてください。

　こっから先は、どうぞ。
　もしかしてＤＯＳエミュに原因が、、、とか、あるの？

混線しているのでここにつけます。

> >これはつまり、どちらでもヒットするはず、ということですか。
> >結果的には fgrep のほうだけヒットしたので、メタキャラの解釈にバグがあるかもしれないということ？

そもそもの混乱の発端はこの書き込みでしたね。
結論から言うとこの書き込みは間違いでした。
文太さんは、これはおかしいんじゃないかと言いたかったのですね。やっと理解できました。

上のバグか？　という書き込みは寝室のPCでやった結果なのですが、別のPCで試したらどちらでもヒットしました。
それで寝室PCに問題の原因があると思い、VTDOSのメモリ状態を疑ったりDISCを疑ったりもしました。
最後に grep.exe の存在確認をしたら・・・あると思っていたものが無かったのです。

> 　grep で結果が出ず（ヒットなし）、fgrepで結果が出る（ヒットあり）。何かおかしいようには
> 思われます。
> 　konnoさんが考えていること、というより、konnoさんがやっていることが、僕にはよく読めて
> いないような感じがしています。
> 　ちゃんとしたツールで、「漏れ」とか、あってはいけないような気がします。

つまり、私が大ポカミスをしていたということで、文太さんの疑念が正しかったのでした。m(__)m
何故そうなったのか。リネームして退避していた実行ファイルを戻す。と言う操作をしたときに誤操作したのか？

実行ファイルのフォルダには ｅ の欠けたファイルが残っていました。
2009/02/13  09:19            96,256 grep.ex
しかしこれは元のファイルとは日付の時間が微妙に違っています。
2009/02/13  17:19            96,256 grep.exe　　元のファイル
FC BIN で比較すると中身は同じでした。・・・ん？ もしかして標準時間の差？
どうもコピー時にトラブってこうなったように見えますが、わかりません。

では、存在しないはずの grep はどこから呼ばれたのか？ Windowsのファルダにはありませんでした。
PATH=c:\ut;c:\;c:\bcc\bin;c:\tc;c:\tc\INCLUDE;c:\tc\LIB;c:\windows;c:\windows\system32;
パスを順に見ていったら、\tc\ の中にありました。(^^;
 C:\TC のディレクトリ
1989/05/11  02:01             7,029 GREP.COM

これは古いですね。だから再帰で読めなかったのでしょう。
大変お騒がせしてすみませんでした。m(__)m


＃　大山鳴動して鼠一匹とはこのことか（違

konnoさん

>パスを順に見ていったら、\tc\ の中にありました。(^^;
> C:\TC のディレクトリ
>1989/05/11  02:01             7,029 GREP.COM

　ここでいちばん笑いました。

　で、その２つの３２ビットＧＮＵ・ＧＲＥＰなのですが、動きます？
もちろん、僕は昨晩ＤＬしたのを解凍したのですが、pcre32.dllがない、
とかで動かせませんでした。

2009/02/13  09:19            96,256 grep.ex
2009/02/13  17:19            96,256 grep.exe　　元のファイル

　このタイムスタンプの差には気が付いていました。

>リネームして退避していた実行ファイルを戻す。と言う操作をしたときに
>誤操作したのか？
　ありえますね。
　わざと、exe -> ex をした可能性もあるかも。意図してやったのに、
忘れた、とか。僕ならありえます。

　しょうがないので、超絶技を披露いたしましょう！

　３２ビットアプリでグレップしたい。ディレクトリ再帰もさせたい。
　３２ビットのグレップはどうもあまりうまいのが見つからない。
　では、３２ビットの awk、mawk32.exeにやってもらおう。awkに
ディレクトリ再帰の機能はないから、wild32.exe に手伝ってもらおう。

　方針は、
（１）ヒットするファイルをディレクトリの奥深くに置いておく。
（２）グレップ用スクリプトは、「あ」がいっぱい並ぶ行をグレップ（抽出）せよ。
（３）wild32 でリカーシブせよ。
（４）結果は大量の０バイトファイルと、少数のヒット行を含む、対象と同名のファイル、
　　　となるはず。


C:\WK>type t.txt			;これにヒットさせるつもり（１）
ああああああああああああああああああああ	;２０個のはず。see ★

C:\WK>move t.txt c:\tk\vzlog\dc\01	;ヒットさせるファイルをvzlog
					;ディレクトリの奥に置く
C:\WK>type t.awk			;awk スクリプト（printを省略できる）
/あああああああ+/			;（２）これでグレップと同じ機能

C:\WK>wild32 -R "mawk32 -f t.awk $f >c:\wk\$x" c:\tk\vzlog\dc\*.*
expand wildcard & excute command - WILD version1.50 (c) 1996-99 by namazu & Si
74 file(s) is found			;74個の対象ファイルです！　74個グレップせよ。
					;wild32 でリカーシブ（再帰）だ（３）
C:\WK>dir				;結果です
 C:\wk のディレクトリ

2024/11/23  15:55                 0 DC01~012.LOG	;対象ファイルと同名の結果ファイル
2024/11/23  15:55                 0 DC02.LST		;もちろん、ノン・ヒットなので
2024/11/23  15:55                 0 DC02_968.LOG	;ゼロバイト
2024/11/23  15:55                 0 DC02_981.LOG
2024/11/23  15:55               152 DC06C967.LOG	;ここには偶然、いっぱい
（いっぱい中略）					;「ああああああ」がいた
2024/11/23  15:55                 0 DC18C995.LOG
2024/11/23  15:55                 0 DC18C996.LOG
2024/11/23  15:55                 0 DC19C973.LOG
2024/11/23  15:55                 0 DC19~021.LOG
2024/11/23  15:55                 0 DC19~027.LOG
2024/11/23  15:55                 0 DC20B9A1.LOG
2024/11/23  15:48                27 t.awk		;スクリプト
2024/11/23  15:55                42 t.txt		;ヒット！　結果ファイルです。
							;15:55 が上のノンヒットのログと同じ
							;★＝「あ」が２０個＋CRLF

　繰り返しっぽいですが、vzlog\dc 以下に７４個の対象ファイルがあり、
c:\wk に７４個の結果ファイルができるあがる仕組みです。

　同じことが、DOSVAXJ3 で、できればいいんじゃない？
　３２ビットアプリＸ２、ですが。

C:\WK>type c:\tk\vzlog\dc\01\t.txt
愛愛愛愛愛

C:\WK>yagrep -r "愛愛愛愛愛" c:\tk\vzlog\dc\*.*
c:\tk\vzlog\dc\01/t.txt:愛愛愛愛愛		;最後だけスラッシュなのは、
						;その前までをコマンドラインから
						;コピーしてるからでしょう。
						;読みづらい。
C:\WK>ygrep -r "愛愛愛愛愛" c:\tk\vzlog\dc\*.*
c:\tk\vzlog\dc\01\t.txt        1:愛愛愛愛愛	;読みやすい！

　同じテストが上のかたちでできたのは、yagrep.exe と ygrep.exe だけでした。
　前回と同じく７４個のファイルを舐めたはずです。
　もちろん、yagrep.exe は３２ビット、ygrep.exe は１６ビットアプリです。

　yagrepは、「表」「十」とかでもこけた。残念、信頼感なし。
　ygrepは、このあたりは見事クリアしました。
　wgrepは、再帰では動かせなかった。

　もちろん、VTDOS環境です。

　wgrep.doc を読んで、なんでできない？　に答えを求めました。
　考察の結果です。「再帰」ではないです。
　一層下だけ、という意味みたいです。wgrep.docからは、そうは読めないと
思うけど。


----- wgrep.doc -----

----------------------------------------
　　-u 　　　　　　　:サブディレクトリも検索
----------------------------------------

　該当のディレクトリ下の全てのディレクトリ、ファイルを検索対象とします。

　検索の対象となるディレクトリは以下の様になります。

　　　　［ドライブ：］［￥］［ディレクトリ￥］ファイル名
          |             |                     |
          |             |                     +----ﾜｲﾙﾄﾞｶｰﾄﾞが利用出来ます。
          |             +----ﾃﾞｨﾚｸﾄﾘの先頭に\が無いとｶﾚﾝﾄﾃﾞｨﾚｸﾄﾘ下のﾃﾞｨﾚｸﾄﾘを検
          |                  索対象とします。
          +----ドライブの指定が無いとカレントドライブを対象とします。

　例を次に示します。

          a:\test.*      Aﾄﾞﾗｲﾌﾞの全ﾌｧｲﾙ中でtest.*のﾌｧｲﾙ
          \test.*        ｶﾚﾝﾄﾄﾞﾗｲﾌﾞの全ﾌｧｲﾙ中でtest.*のﾌｧｲﾙ
　　　　  a:\work\test.* Aﾄﾞﾗｲﾌﾞのﾃﾞｨﾚｸﾄﾘwork下の全ﾌｧｲﾙ中でtest.*のﾌｧｲﾙ
　　　　  work\test.*    ｶﾚﾝﾄﾄﾞﾗｲﾌﾞのｶﾚﾝﾄﾃﾞｨﾚｸﾄﾘのﾃﾞｨﾚｸﾄﾘwork下の全ﾌｧｲﾙ中で
　　　　　　　　　　　　 test.*のﾌｧｲﾙ

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


C:\>wgrep -u "愛愛愛" C:\tk\vzLOG\dc\01\*.*
------------------ C:\TK\VZLOG\DC\01\T.TXT
愛愛愛愛愛

C:\>wgrep "愛愛愛" C:\tk\vzLOG\dc\01\*.*	; -u オプションなし
------------------ C:\TK\VZLOG\DC\01\T.TXT	; 結果は上に同じ。-u の意味、ないじゃん
愛愛愛愛愛

C:\>wgrep -u "愛愛愛" C:\tk\vzLOG\dc\*.*	;dcフォルダの下の01フォルダに
ファイルが読めません ---> C:\TK\VZLOG\DC\*.*	;ヒットすべきファイルがある


　「再帰」を使いたい場合は、ygrep.exe にお仕事を頼むのが良いと思います。
　nifty 過去ログに、これに関する発言はなかったようです。誰も使ってない。

　総じて、Windows 時代になってからの、これらテキスト処理ツールの進化は
あまり大きなものではなかった、ということだと思います。
　みなＬｉｎｕｘが普通に使えたので、Windows のコンソールでテキスト処理を
する必要がなかったのでしょう。ＧＮＵもののWin32への移植も、あまり輝かしい
成功をおさめたとも思えませんし。
　僕は、特殊な場合以外（ＰＣオーディオ）、とりわけＬｉｎｕｘ的世界に
魅力は感じていませんが。
　純ＤＯＳ機とWinME。これらをはやく調整して調達しないと。

> 　wgrep.doc を読んで、なんでできない？　に答えを求めました。
> 　考察の結果です。「再帰」ではないです。
> 　一層下だけ、という意味みたいです。wgrep.docからは、そうは読めないと
> 思うけど。

それはおかしい。
私、PC-98の時代から、該当ディレクトリ下部一括検索をする時はいつもwgrepを
使っていました。そして、３０年余りの経験で、検索漏れに気がついたことは
一度もない。
そして今、WinXPをひっぱりだしてきてVTDOS122でwgrepを使ってみました。
結果、少なくとも３階層くらい下までは引っ張ってきてくれています。
なお、以下表示の右端側は省略しています。

> VTDOS|D:\TOSHIKI\NIF>type C:\FREEWARE\DOS\WGREP.CFG 
> -i -j15 -s7 -u -h3 -t
> 
> VTDOS|D:\TOSHIKI\NIF>wgrep -u "grep" *.txt
> NIFTY\FGALDC\MES13\09260.TXT 14:これは grep を使って検索するときも同様でし
> NIFTY\FGALDC\MES13\09260.TXT 18:定正規表現を使わずに検索できる時には、grep 
> NIFTY\FGALDC\MES13\09266.TXT 7:》定正規表現を使わずに検索できる時には、grep 
（以下略）

少なくとも私のVTDOS環境では、PC-98の生DOS環境と同様、きちんと再帰検索できて
います。

> 　「再帰」を使いたい場合は、ygrep.exe にお仕事を頼むのが良いと思います。

こちらに対しては特に異を唱えるものでもありませんが、

> 　nifty 過去ログに、これに関する発言はなかったようです。誰も使ってない。

こちらに対しては小異あり。
ygrepを誰も使っていない、なんて事はないと思う。
あるいは、仕様どおりというか全く何も問題がなかったから発言がなかった、という
見方もできるかも。

> C:\>wgrep -u "愛愛愛" C:\tk\vzLOG\dc\*.*	;dcフォルダの下の01フォルダに
> ファイルが読めません ---> C:\TK\VZLOG\DC\*.*	;ヒットすべきファイルがある

うん、実は気がついていない人が多いのですが、こうなる可能性があるパターンと
いうのがありまして。
dcフォルダの下の01フォルダにヒットすべきファイルが仮にあったとしても、
dcフォルダそのものにファイルが１つもない場合、このメッセージが表示されるの
ですよ。
その場合、dcフォルダにダミーファイルを１つ作ってやれば、うまくヒットします。
ファイル名は何でもよろし。dummy.xlsでも何でもOK。

　以下をどう読むかは難しそう。たしかに普通のディレクトリ構成なら
３階層ぐらいはいけそう。僕の環境では、dcが起点だと、まともなのは
１階層ですけれど。

C:\TK\VZLOG>wgrep -u "愛愛愛" C:\tk\*.*
メモリが不足しています

C:\TK\VZLOG>wgrep -u "愛愛愛" C:\tk\vzlog\*.*
------------------ C:\TK\VZLOG\DC\01\T.TXT
愛愛愛愛愛
メモリが不足しています		;たぶん運よくヒットできた

C:\TK\VZLOG>wgrep -u "愛愛愛" C:\tk\vzlog\dc\*.*
------------------ C:\TK\VZLOG\DC\01\T.TXT
愛愛愛愛愛

　でも、ファイルがないディレクトリだけの階層は挟むな、これで
ＯＫです。
　としきさんに多謝。すげえな、やっぱり。年季がちがう。
　だって、あれだけの連投を読み込んだうえでの、これだよ。
　ほんと、ありがと。

としきさん

>朝起きたら市内一斉清掃に参加しなければならぬ。

　おはようございます。そして、お疲れ様でした。近所がきれいに
なりましたよね。
　うちは当番制なので、今年は奥様がやってきました。

>> でも、なんでこんなこと知ってるの？
>経験者だから。
　なるほど。

>私がよくやるのは、*.txt なんてファイル指定なんですが、
　abc??.txt という指定では、いつもできてるのに、今日は「*.txt」で
エラーが出るぞ、という経験があれば、論理的に考えますね。さすが。
経験は強し。

>今回の文太さんの例だと、ファイル指定が *.* となっていたから、
　ビンゴ！　ディレクトリのみ１４個でした。論理的、ふたたび。

C:\TK\VZLOG\DC>dir

2024/11/24  00:48    <DIR>          .
2024/11/24  00:54    <DIR>          ..
2024/11/23  19:12    <DIR>          01
2023/06/02  20:17    <DIR>          02
2023/06/02  20:17    <DIR>          04
2023/06/02  20:17    <DIR>          06
2023/06/02  20:17    <DIR>          13
2023/06/02  20:17    <DIR>          14
2024/11/23  15:53    <DIR>          15
2023/06/02  20:16    <DIR>          17
2023/06/02  20:16    <DIR>          18
2023/06/02  20:16    <DIR>          19
2023/06/02  20:16    <DIR>          20
2023/06/02  20:17    <DIR>          ct

　FGALDC １階から２０階まで。じつは、としきさんの
アドバイスで、aaa.txt 0 byte が、今まで入ってました。消したけど。
ygrep.exeにそんな制限ないもん。

としきさん

> VTDOS|D:\TOSHIKI\NIF>type C:\FREEWARE\DOS\WGREP.CFG
> -i -j15 -s7 -u -h3 -t                           ~~~
              ~~　
　そうそう、これです。PK/DC ログを、ygrepの「発言アーティクル」
単位検索で、"wgrep:再帰" のアンド検索をしたら、唯一出てきたのが
この部分への言及。「環境変数で設定してます」by としき、でした。

> > 　wgrep.doc を読んで、なんでできない？　に答えを求めました。
> > 　考察の結果です。「再帰」ではないです。
> > 　一層下だけ、という意味みたいです。wgrep.docからは、そうは読めないと

wgrep は再帰検索に失敗することが有るので、この説明に納得しかけましたが

> それはおかしい。
> 私、PC-98の時代から、該当ディレクトリ下部一括検索をする時はいつもwgrepを
> 使っていました。そして、３０年余りの経験で、検索漏れに気がついたことは
> 一度もない。
> そして今、WinXPをひっぱりだしてきてVTDOS122でwgrepを使ってみました。
> 結果、少なくとも３階層くらい下までは引っ張ってきてくれています。

そ、そうなんですか。

> > C:\>wgrep -u "愛愛愛" C:\tk\vzLOG\dc\*.*	;dcフォルダの下の01フォルダに
> > ファイルが読めません ---> C:\TK\VZLOG\DC\*.*	;ヒットすべきファイルがある
> 
> うん、実は気がついていない人が多いのですが、こうなる可能性があるパターンと
> いうのがありまして。
> dcフォルダの下の01フォルダにヒットすべきファイルが仮にあったとしても、
> dcフォルダそのものにファイルが１つもない場合、このメッセージが表示されるの
> ですよ。
> その場合、dcフォルダにダミーファイルを１つ作ってやれば、うまくヒットします。
> ファイル名は何でもよろし。dummy.xlsでも何でもOK。

今まで wgrepの再帰検索は不安定だなぁと思っていたのですが、そういうことでしたか。
大変有益な情報をありがとうございます。

> 　で、その２つの３２ビットＧＮＵ・ＧＲＥＰなのですが、動きます？
> もちろん、僕は昨晩ＤＬしたのを解凍したのですが、pcre32.dllがない、
> とかで動かせませんでした。

このDLLは ZIPの中には無いですね。私は多分 SETUP.EXE から落としたのでしょう。

#11677 
> #10343： Re: win7 bupdate 投稿者: konno 　 2022/10/18
> 　このあたりが近いかもしれない。

多分そのころです。
2018/10/06  00:36           451,824 grep-2.5.4-bin.zip
この日付の前は #8214
> > >Grep (GNU) 需要予測 1.txt
> > 需要予測
> おお、GNUGrep は大丈夫なんですか。
> ちょっと探してみます。
多分この後に落としたんでしょうね。
私の使い方では検索漏れも少ないみたいなのでこれ以降再帰検索ではずっと愛用しています。
WILD は GREP で使うにはあまり向いていないと思うので、別の機会に。

　32ビットの日本語対応グレップ、だと思う。awk-like な拡張正規表現が
使える模様。

www.vector.co.jp/soft/winnt/util/se365621.html

　Win11で、動くことだけ確認しました。もともとgrep.exeというファイル名
だったのですが、これではちょっと使いづらいので、作者の名前から、
popogrep.exeとリネームしました。
　あまり使う予定はないものですから。

C:\WK\POPOGREP>popogrep
Parameter error
 Usage : 
grep [option] string file

[option]
  -i : 比較中に大文字と小文字を区別しない
  -c : パターンを含む行の数だけを表示する
  -n : 各行の先頭に、ファイルにおけるその行の行番号を出力しない
  -v : パターンを含む行を除いたすべての行を出力する
  -p : 結果出力時にファイルのパスを表示しない
  -f : 結果出力時にファイルのパスをフルパス表示する（デフォルトは相対パス表示）
  -r : サブディレクトリも再起的に検索する　【あるじゃん！】

string : Grep対象文字列
         正規表現可
         ex)
            grep .+[abc]+ file

file   : ファイル名
         ワイルドカード可
         ex)
            grep abc *.txt

C:\WK\POPOGREP>type t.txt
表
十
愛

C:\WK\POPOGREP>popogrep "表" t.txt
popogrep.txt(17): と入力するとテキストファイルから"ABCDEFG"を含む行を全て抽出して画面に表示
popogrep.txt(26): ２．正規表現を使用することもできます。
popogrep.txt(32):     正規表現については、別途参考書等を参照してください。
popogrep.txt(39):      -c : パターンを含む行の数だけを表示する
popogrep.txt(42):      -p : 結果出力時にファイルのパスを表示しない
popogrep.txt(43):      -f : 結果出力時にファイルのパスをフルパス表示する（デフォルトは相対パス表示）
popogrep.txt(76): 起動時に何らかのエラーが表示される場合には、
t.txt(1): 表十

C:\WK\POPOGREP>popogrep 表 t.txt
popogrep.txt(17): と入力するとテキストファイルから"ABCDEFG"を含む行を全て抽出して画面に表示
popogrep.txt(26): ２．正規表現を使用することもできます。
popogrep.txt(32):     正規表現については、別途参考書等を参照してください。
popogrep.txt(39):      -c : パターンを含む行の数だけを表示する
popogrep.txt(42):      -p : 結果出力時にファイルのパスを表示しない
popogrep.txt(43):      -f : 結果出力時にファイルのパスをフルパス表示する（デフォルトは相対パス表示）
popogrep.txt(76): 起動時に何らかのエラーが表示される場合には、
t.txt(1): 表十

C:\WK\POPOGREP>popogrep 愛 t.txt
t.txt(3): 愛

　ま、バグってはいます。
　たぶん、

C:\WK\POPOGREP>popogrep 表 t.txt
が

C:\WK\POPOGREP>popogrep 表 *.*
か
C:\WK\POPOGREP>popogrep 表 *.txt
と解釈されているのでしょう。

　もちろん、かなり意地悪なテストです。こんな結果になるとは思わなかった
のだけど。

> FC BIN で比較すると中身は同じでした。・・・ん？ もしかして標準時間の差？
> どうもコピー時にトラブってこうなったように見えますが、わかりません。

う〜ん、８時間の差、というのがよくわかりませんね。
９時間の差、というのはUTCとJSTの解釈ミスで時々見かけますけど。
あと、かなり昔のアメリカ製の圧縮ソフトで、夏時間の解釈を間違って圧縮時だか
解凍時に１時間狂わせる、というのがあったそうですが、最近のソフトでそういう
ものがあるとは思えない。けど、むしろＭＳ純正のソフトでありそうな気がするのは
私の偏見か。

> パスを順に見ていったら、\tc\ の中にありました。(^^;
>  C:\TC のディレクトリ
> 1989/05/11  02:01             7,029 GREP.COM

うぉ、これも懐かしいですね。TurboC 2.01だ。
実家に行けば、今でも残っているかも。

> >  C:\TC のディレクトリ
> > 1989/05/11  02:01             7,029 GREP.COM
> 
> うぉ、これも懐かしいですね。TurboC 2.01だ。
> 実家に行けば、今でも残っているかも。

珍しくフットワーク軽く、実家に行ってきました。タッチアンドゴー。
結果。
実家にあったのはTurboC 2.00。

1988/12/20  02:00             8,263 GREP.COM

こんなものあったんだ。たぶん、使った事はない。

　僕はこんなのを見つけました。


C:\TC\TC15>dir grep.com
1988/01/25  01:05             5,930 GREP.COM

C:\TC\TC15>grep
Turbo GREP	Version 1.0  Copyright (c) 1987 Borland International
Syntax is:	GREP [-rlcnvidzw] searchstring file[s]
		GREP ? for help

C:\TC\TC15>grep ?
Turbo GREP	Version 1.0  Copyright (c) 1987 Borland International
Syntax is:	GREP [-rlcnvidzw] searchstring file[s]

Options are one or more option characters preceeded by "-", and optionally
followed by "+" (turn option on), or "-" (turn it off).  The default is "+".
   -r*  Regular expression search	-l   File names only
   -c   match Count only		-n   Line numbers
   -v   Non-matching lines only		-i   Ignore case
   -d   Search subdirectories		-z   Verbose
   -w   Write default options
(Options flagged with a "*" are on by default)

A regular expression is one or more occurrences of:  One or more characters
optionally enclosed in quotes.  The following symbols are treated specially:

   ^  start of line		$  end of line
   .  any character		\  quote next character

   a*  match zero or more a's
   a+  match one or more a's

   [aeiou0-9]	match a, e, i, o, u, and 0 thru 9
   [^aeiou0-9]	match anything but a, e, i, o, u, and 0 thru 9



C:\TC\TC201>dir grep.com
1989/05/11  11:01             7,029 GREP.COM

C:\TC\TC201>grep
Turbo GREP  Version 1.2  Copyright (c) 1987, 1988 Borland International
Syntax:  GREP [-rlcnvidzuwo] searchstring file[s]
         GREP ? for help

C:\TC\TC201>grep ?
Turbo GREP  Version 1.2  Copyright (c) 1987, 1988 Borland International
Syntax:  GREP [-rlcnvidzuwo] searchstring file[s]

Options are one or more option characters preceeded by "-", and optionally
followed by "+" (turn option on), or "-" (turn it off).  The default is "+".
   -r+  Regular expression search	-l-  File names only
   -c-  match Count only		-n-  Line numbers
   -v-  Non-matching lines only		-i-  Ignore case
   -d-  Search subdirectories		-z-  Verbose
   -u-  Update default options		-w-  Word search
   -o-  UNIX output format		     Default set: [0-9A-Z_]

A regular expression is one or more occurrences of:  One or more characters
optionally enclosed in quotes.  The following symbols are treated specially:
   ^  start of line		$  end of line
   .  any character		\  quote next character
   *  match zero or more	+  match one or more

   [aeiou0-9]	match a, e, i, o, u, and 0 thru 9
   [^aeiou0-9]	match anything but a, e, i, o, u, and 0 thru 9


　上は一部フィクションを含みます。C:\TC なんてディレクトリ、この遊びっけ
なしのマシンに存在するわけがありません。遊びマシンは、１年以内くらいに
作ります。
　これら grep.com は、もちろん使ったこと、ありません。使う予定もありません。
　日本語対応ない grep が、日本語環境でどう振る舞うか、とか調べる気はありません。


konnoさん、TurboC 2.01
 1989/05/11  02:01             7,029 GREP.COM --- 一緒、タイムスタンプ異

としきさん、TurboC 2.00
 1988/12/20  02:00             8,263 GREP.COM

文太、TurboC 1.5
 1988/01/25  01:05             5,930 GREP.COM

文太、TurboC 2.01
 1989/05/11  11:01             7,029 GREP.COM --- 一緒、タイムスタンプ異

追記：Turbo grep には、ver. 1.0 から、「ディレクトリ再帰」がある！
　-d   Search subdirectories

> konnoさん、TurboC 2.01
>  1989/05/11  02:01             7,029 GREP.COM --- 一緒、タイムスタンプ異

> 文太、TurboC 2.01
>  1989/05/11  11:01             7,029 GREP.COM --- 一緒、タイムスタンプ異

かっきり９時間ですからねぇ。
どこかでタイムスタンプを狂わせる圧縮／解凍ツールを使った可能性が高そうな
結果ですね。

konno wrote:
--------------------------
私の手持の GREP のZIPが32ギガのUSBメモリの中にありました。
grep-2.5.4-bin.zip
2018/10/06  00:36           451,824 grep-2.5.4-bin.zip
\bin\
2009/02/13  17:19            92,160 egrep.exe
2009/02/13  17:19            54,784 fgrep.exe
2009/02/13  17:19            96,256 grep.exe
--------------------------

grep-2.5.4-bin.zipをぐぐったところ

https://ja.osdn.net/projects/sfnet_gnuwin32/downloads/grep/2.5.4/grep-2.5.4-bin.zip/
で見つかり、grep-2.5.4-bin.zipを展開したら

2024/11/23  01:06            92,160 egrep.exe
2024/11/23  01:06            54,784 fgrep.exe
2024/11/23  01:06            96,256 grep.exe

　というものが得られました。タイムスタンプは、まったくあてに
ならないようですが、ファイルサイズはドンピシャです。
　が、これ、日本語対応してるのでしょうか。

　展開後に、share\locale\ja というのがあり、エラーメッセージを日本語
表示するためのファイルみたいなのがあるみたいでした。

　よく分かりませんが、その grep 、日本語対応してますか？
　ドキュメントが英語で、それが読めないとなると、素直に日本のベクタに
登録されているものを使ったほうが安全みたいな気がします。
　わからんちんの文太ですが。

　独り言発言です。
　何が話題だったか思い出せませんが、きっと２年くらい前に、アーカイブ
ファイルを展開すると、あるいはファイルをＤＬすると、その展開日、
あるいはＤＬ日にタイムスタンプが変更されてしまうみたい（Win7あたりから？）
という話がありました。

#10343： Re: win7 bupdate 投稿者: konno 　 2022/10/18

　このあたりが近いかもしれない。

　で、昨晩の「grep-2.5.4-bin.zip」を、Win11 右クリック「すべて展開」と
（いわば）プリミティブなＬＨＭｅｌｔで試したところ、後者では
タイムプタンプが保持されました。

2009/02/13  09:19            92,160 egrep.exe
2009/02/13  09:19            54,784 fgrep.exe
2009/02/13  09:19            96,256 grep.exe

　こんな具合。右クリックが楽なのですが、お仕事まわり以外では、わざわざ
ＬＨＭｅｌｔを使おうと思います。もちろん関連付けされているので、
ダブルクリックするだけなのですが。

C:\>dir c:\bin | grep -i "grep"
1992/05/03  06:47            78,419 CGREP.EXE
1994/10/06  13:01            50,672 DGREP.EXE
1994/06/02  18:50            90,959 EGREP.EXE
2003/04/14  00:00            80,412 FGREP.EXE	;サイズが違うのでリネームではない
1994/06/02  18:50            90,959 GREP.EXE
1993/04/11  16:05            23,997 IZGREP.EXE
1994/04/30  10:07            66,700 YGREP.EXE

　使い分けているわけでもないです。ここ１週間弱を除けば、１年ぐらい
どれも使っていないような気がします。どれにも、とりわけバグとかあるように
感じたことはありません。気づくのがけっこう大変だとは思いますが。
　作者様たちに感謝、感謝です。

　ygear.def by とらじにはメニューを仕込んであるので、特定のプロジェクト
の時に、ygrep.exeを集中的に使う。
　ふだんは、grep.exe か izgrep.exe (高速)。前後とかの文脈（コンテクスト）
を見るときには、cgrep.exe でしょうか。
　プログラムのソースには、メタ文字のたぐいがけっこう入っているときが
あります。こういう場合には、（頻繁ではなかったですが）fgrep.exe のおでまし
となっていたと思います。

　純粋な実行ファイルではありませんが、grep.def by tomo も、昔はよく
使いました。^NG と、ちゃんとキーアサインしています。


　余談＆脱線。先日、「ワイルドカードの展開は誰がする？」という弱い疑問を
持ったとき、MS-DOS Encyclopedia と Undocumented DOS を "wildcard" でグレップ
しました。期待していた解答はなかったのですが、ちらちら関連個所を読んで
いて、以下を思いつきました。

normal:	mov	ah,4eh			;FINDFIRST
	mov	dx,offset FILE
	mov	cx,0
	int	21h

FILE	db	'*.*',0

　blt.com (お気に入りツール by Bunta)です。簡易 dir コマンド。
　4Eh, int 21h が、ワイルドカードを使ってる。つまり、元はmsdos.sysが
配置したベクターテーブルの先のルーチンがワイルドカードの展開をしている
（Encyclopediaによれば、DOS では、*.* は、????????.???に展開される
らしいのだが）。
　ですから、誰が展開する？　に対する回答は、【その場合】ＤＯＳエミュ
ということになると思います。
　が、８．３以上のファイル名を受け付けるためには、、、。
　決まったやり方があるのでしょうが、大変そうですねぇ、という感想でした。
　因みに、blt.comには、ＬＦＮを受け付ける兄貴、bll.comというのもあります。
Windows仕様の長いファイル名を受け付けるやつ。

normal:	mov	ax,714eh		;FINDFIRST
	mov	dx,offset FILE
	call	SET			;set cx, si, di
	int	21h

　こちらでは、714eh というファンクションになっているようです。
つまり、ＯＳが片づけてくれてるんですね。VTDOSでは、どちらも完全に
動いています。
　もちろん、VTDOSは、ときどき落ちるのですが。

> C:\>dir c:\bin | grep -i "grep"
> 1992/05/03  06:47            78,419 CGREP.EXE
> 1994/10/06  13:01            50,672 DGREP.EXE
> 1994/06/02  18:50            90,959 EGREP.EXE
> 2003/04/14  00:00            80,412 FGREP.EXE	;サイズが違うのでリネームではない
> 1994/06/02  18:50            90,959 GREP.EXE
> 1993/04/11  16:05            23,997 IZGREP.EXE
> 1994/04/30  10:07            66,700 YGREP.EXE

あはは、懐かしいものがいっぱい。
うちの場合はこう。

c:\>dir /s c:\*.exe c:\*.com | find /i "grep" | sort /+36
1994/10/06  00:00            50,672 DGREP.EXE
2000/09/13  17:21            69,632 egrep.exe
1986/03/11  02:09            10,260 FGREP.EXE
1998/08/31  04:00           102,400 grep.exe
1988/05/02  02:56            17,551 GREP.EXE
1993/12/01  01:53            19,884 WGREP.COM

CGREPは評価はしたことはあるはず。
http://toshiki.la.coocan.jp/computer/library/ls-lr.txt
によると、持っていることは持っているから。バージョンは違うかもしれないけど。
DGREPは同じものっぽいけど、微妙にタイムスタンプが違うのはなぜだろう。
egrepはいろいろと謎。タイムスタンプから３２ビット対応だとは思う。ドキュメント
の類似性から新出さんのUnix like toolsのものだと思うけど、ドキュメントには
日本語非対応と明記してあった。そして、そのドキュメントには、同一パッケージ内
にjegrepが同梱されていると書いてあったけど、なぜか私は使っていない模様。
そしてドキュメントには、遅いと明記してある。
FGREPは ASCII tools の名ばかりgrep。なぜ名ばかりかというと、正規表現に対応して
いないから。きちんと対応したのがGREP.EXE。一方、grep.exeのほうはDELPHIの
おまけのツール。使ったことがない。
WGREPはなぜ文太さんが使っていないのか、不思議。

余談ですが、IZGREPとYGREPも、ドキュメントは読んだ記憶があるような。
そして、他のGREPにはなくてこれらのGREPにある機能で私が必要とするものがないので
導入しなかった、ようなうろ覚えの記憶。
一方でyagrepは、私は明らかに使ったことがない。入手したことすらないはず。

c:\>dir /s c:\*.exe c:\*.com | find /i "grep" | sort /+36
994/10/06  00:00            50,672 DGREP.EXE

　あはははは。楽しい。でも、その話でなく、

994/10/06　は
1994/10/06　ですよね。

　この掲示板の「あれ」なのでしょうか　＞konnoさん

#11692
> c:\>dir /s c:\*.exe c:\*.com | find /i "grep" | sort /+36
> 994/10/06  00:00            50,672 DGREP.EXE

この多段パイプ技も目を引きましたが

> 994/10/06　は
> 1994/10/06　ですよね。
> 　この掲示板の「あれ」なのでしょうか　＞konnoさん

この意味がわかりませんでした。

#11699
> あれ、というか「癖」っぽいですね。うん、「ヤマイダレ」のついている漢字だ。
> mode=msgviewのときだけ発病する感じ。
> allreadとかnewsortの時はきちんと欠落なく表示してくれているから。
> そして、行頭が半角「1」は欠落するけど半角「2」なら大丈夫、というのも不思議。
> どうすればこうなるんだろう。

やっとわかりました。
mode=msgviewのときだけ表示が変なのですね。
うちだけなのかな。
確認してみます。


＃　ヤマイダレハシナナキャナオラナイ富士の山異誰？

DOSVAXJ3 (2024/11/18)テスト版のメールをいただきました。
内容は

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

　さらに修正して C# 等で作られた .NET コンソールプログラムでも入力
可能となっています。環境変数の設定は noinput から novc に変更しま
した。
https://www.nanshiki.co.jp/test/dosboxj_test6.zip

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

ということでさらに多くのコマンドに対応されたようです。
ありがとうございます。

また、GAWKの件でも
>> gawk "BEGIN{print mktime("""2004 09 28 20 57 00""")} >utime
>> gawk:                                                ^ syntax error
>　> の前に " が必要です。

とアドバイスをいただきました。これはVZマクロで
=utime
*m
89 ^\ "" #E "gawk $"BEGIN{print mktime($"$"$"2004 09 28 20 57 00$"$"$")} >utime" #m
*
こうなっていて、VTDOSではこれで動いていました。

89 ^\ "" #E "gawk $"BEGIN{print mktime($"$"$"2004 09 28 20 57 00$"$"$")}$" >utime" #m
こう修正したら、VTDOSでも DOSVAXJ3 でもキチンと動きました。ありがとうございます。

入力系＝対話型とすると、CMD.EXE とかでしょうか。
DOSVAXJ3 で dir *grep*  とすると、カレントの全ファイルが表示されます。
CMD
dir *grep*
とすると、grep を含むファイルだけ表示されます。
exit で戻ると VZのコンソールに結果が入っていますね。これはありがたいです。
これは MS-DOS Playerや VTDOSでも出来ましたが、VZコンソールに結果は入りませんでした。