TSfree 発言

　以下、詰められませんでした。## が暫定的なまとめです。

　変な英語、ご容赦。m(_B_)m
　随分経ってから、オプションによって違った振る舞いをする可能性があること
に気づき、大方意味がないのですが、網羅的にコマンドラインの書式を入れまし
た。基本的に BRE でのテストです。

　・改行文字＋量指定子（#2474）
　・半角空白＋量指定子（" [0-9]\+" の問題のみが確認されている）
　・半角空白＋オプション（-R）

　と大まかに分類してよいのでしょうか。このラインはこれ以上に調査は続けら
れないな、と思っています。それでも不具合に遭遇したら報告させていただきます。

Bunta


--- test.sed ---
#Onigsed -f test.sed
/ /!d
----------------
--- test.txt ---
 this_is_whitespace	#OK, this line is successfully extracted.
	this_is_tab
----------------
## Single whitespace does not have any problem.

then, the problem is more complex ... ;-)   I'm weeping, not smiling.
Or the whitespace matching may not be really the buggy place ....
OK, let's get back to where the things originally started.


.... time lapsed, and after a lot of tears ....


Potentially meaningful examples are shown below:

--- test.txt ---
v.c./vz 43番
----------------
--- test.sed ---		# quantifier used
#Onigsed -f test.sed
/^v\.c\.\/vz [0-9]\+番/!d		NG (1)
----------------
--- test.sed ---		# quantifier not used
#Onigsed -f test.sed
/^v\.c\.\/vz [0-9][0-9]番/!d		OK
----------------


--- test.txt ---
v.c./vz43番			# without whitespace
----------------
--- test.sed ---		# quantifier used
#Onigsed -f test.sed
/^v\.c\.\/vz[0-9]\+番/!d		OK
----------------
## no whitespace but quantifier-used situation;
## Whitespace has something to do with this bug.  SEE (1) above.
## But again, the quantifier is playing some part here, too.  SEE (1) above.


To the whitespace issue,

from #2430, Fujioka-san wrote (a little chaged):
thanks, Fujioka-san. m(_B_)m

-----^ data.txt
v.c./vz 43
a 1
-----$
-----^ a.sed			# with no option == BRE
#Onigsed -f a.sed data.txt
/[a-z] [0-9]/!d			OK
-----^ a2.sed			# with -R (Perl-like) option
#Onigsed -R -f a2.sed data.txt	# option switch affects the buggy place
/[a-z] [0-9]/!d			NG
-----$

## Option switch, too, seems to affect the buggy place with regard to the
whitespace problem.  But this is too complex to analyze further.  

Sorry,  >Bruce.san
I have to give up ....


Bunta