On Wed, Aug 8, 2012 at 6:11 PM, Glenn Fowler <g...@research.att.com> wrote: > > On Wed, 8 Aug 2012 16:20:48 +0200 Cedric Blancher wrote: >> On 8 August 2012 16:10, Glenn Fowler <g...@research.att.com> wrote: >> > >> > the next betas will be alphas >> > "alpha" means that each release will be possibly significantly different >> > from the previous >> > especially in api headers and prototypes >> > >> > the poll builtin will be in the next alpha > >> Three cheers and a tiger! :) >> *party* > >> grep and its fellows od, tr and xgrep are still persona non grata in >> the libcmd clubhouse? > > b_poll is an invention with no possible alternative implementation clashes
I don't understand this concern. What exactly is the problem? Portability is certainly not an issue, AST grep is compatible to the AIX, HP/UX and Solaris implementations of grep and has almost all options of coreutils grep (and certainly all of the sane ones, -Z, --null print 0 byte after FILE name does IMHO no longer count as "sane"). The good side of such a change would be that this will actually *improve* portability of ksh93 shell scripts - there would finally be a grep implementation available on all platforms which works; I say that as long-term sufferer from Solaris /usr/bin/grep and /usr/xpg4/bin/grep (not listing the wide range of grep atrocities (BUGS!) in other Unices), the first one doesn't grok french in UTF8, the latter one's just good enough to run the XPG test suites and crashes on real world data. AST grep is faster than GNU grep too, and as shell builtin there are no pattern length limits which is a plus on some platforms, too. > we have to tread lightly with grep etc. ksh93v is in it's alpha phase. Can't you just make a leap of faith and add it to libcmd? Please? You can always yank it out again if there's trouble which can't be solved before ksh93v+ Irek _______________________________________________ ast-developers mailing list ast-developers@research.att.com https://mailman.research.att.com/mailman/listinfo/ast-developers
