| |
横から失礼します。
杉浦 まさき です。
>本来の質問である grep が複数行を、検索結果として扱うかどうかの本来の仕様
>は、その作者にしか判りません。個人的 (私) は出来ないと思っています。
個人的に色々ハッキング(^^;してみた結果、
秀丸の正規表現検索で検索文字列に改行("\n")を指定した場合、
JRE32.DLL には
検索開始位置から数えて「検索文字列中の "\n" の数 + 1」行が
まとめて送られる、という仕様の様です。
＃その辺は「秀丸Ｑ＆Ａ集」の
「正規表現」の章の最後にコメントしてあります。
＃＃で、これって合ってるんでしたっけ？＞担当様
で、grep の場合はファイル先頭から始めて、
その行数分づつ繰り返し送られているだけだとすると、
その境界にまたがるような物はヒットしないことになります。
とはいえ、他の検索系ツール(grep, sed, awk etc.)も
改行コードの検索に関しては
「サポートしていない」か「自前で処理する」かの
どちらかですから(多分(^^;)、
秀丸は上の仕様になってるだけでもかなり親切なのかもしれません。
>よくマクロで \\n を \n と書いてもまともな結果が
>得られる場合があります。
うーん、要は JRE32.DLL に "\n" という文字列を送るか
改行コードをそのまま送るかの違いですよね。
で、あとは JRE32.DLL が直接改行コードが送られてきた時に
それをどう解釈してるかですけど…
なんか「ケース・バイ・ケース」のようですね(^^;。
>＞^[.]$
>＞だとどの行にも（1charだけの行にも)ヒットしません。
>これは、「.」を文字として、扱うみたいです。ですから、
>^.$ だと、一文字の行をさがします、みたいです。
キャラクタクラス指定子([])の中ではメタキャラクタ(".","*","+" etc.)は
その意味を失って、単なる文字と解釈されます。
で、これは正規表現の標準的な仕様だったと思います。
>教訓、余計な文字は書かない、
これが結構難しかったりしますけど(^^;。
|
|