> > Is there a good reason why the super-sed enhancements are not part of > > the regular GNU sed?
Here are them in order of importance: 1) Lack of response from the maintainer. The bug fixes (not feature enhancements) and the Examples section of the manual were all submitted to Ken Pizzini, and I signed the copyright FSF papers, but they were never made part of a released version or even a CVS repository. 2) Experimental-ness of a few changes. The regex matchings must be verified to be configure-proof on as many architectures as possible, so that installing it does not wreak havoc on a build configuration. For example, sed 3.52 is not perfect under Windows, where it cannot configure sed 3.53 (not yet out). 3) Worse i18n support because of the separate regex matching library. FSF considers i18n and multibyte character support very important. Aid in merging back the UTF-8 support to PCRE, and in using it together with iconv, would be great (also to merge back with PCRE, from which I've forked in order to add a little more performance and POSIX regexp support). Paolo