Glenn, what really angers me is that the requests for grep/od/tr/xargs integration into libcmd have been turned down on the basis of 'too much risk', but in the same time the x=$() doomsday bug crept in and wasn't handled quickly despite a LONG queue of warnings and that a "stable" ksh93u+ was released despite the bug was not corrected.
On 13 June 2012 15:43, Glenn Fowler <[email protected]> wrote: > > [ I added ast-users back to the forwarding list ] > > On Wed, 13 Jun 2012 13:04:33 +0200 Lionel Cons wrote: >> On 13 June 2012 12:39, Lionel Cons <[email protected]> wrote: >> > On 13 June 2012 06:35, Glenn Fowler <[email protected]> wrote: >> >> the AT&T Software Technology ast beta 2012-06-12 source release >> >> has been posted to the download site >> >> http://www.research.att.com/sw/download/beta/ >> >> the package names and md5 checksums are >> >> INIT 534d4fa288fdcf79141b1ec2e71bee8d >> >> ast-base 6a08c19d22027433b0808279e6638097 >> >> ast-open 097c6578696efc82143dbf7fd15b7a83 >> >> ast-ksh 4e2651f7ca60d73636bbe02576ca50d7 >> >> the md5 sums should match the ones listed on the download page >> >> if not then don't download >> > >> > grep wasn't moved to ast-ksh, right? > >> Glenn, David, what exactly is the technical problem which prevents >> grep, od, tr and xargs from being moved to ast-ksh/libcmd? I don't >> understand the technical motivation of not doing this. > > we've stated our case > I'll restate one more time > I guess we have a larger than average (internal not-open-source) user base to > deal with > a lot of ksh usage within that user base is on critical paths > any disruptions obviously cause delays, but it can also damage ksh's rep > and make it harder for us to convince projects to use our stuff > many times ksh and the standard (1) commands are a foot in the door > to other software that we first peddle internally, and then externally > > even the seemingly most simple change can have unforseen consequences > adding a builtin like grep is simple technically > but all of the consequences are not known > operating inside the ksh address space requires a lot of coding discipline > we don't yet know all of the details of that discipline > or its manifestation on different platforms > > sure it was exercised some on linux and solaris > but we have hp, bsd, aix, mvs, cygwin, windows instantiations that haven't > gotten the same treatment > > so please set aside the mostly valid arguments for moving FOO to libcmd > (convenience, efficiency, no approval needed, etc.) and let -lcmdtst > burn in for a while -- let it be thouroughly *beta* tested -- let it be tested > in a way that if a completely catostrophic flaw were found users would simply > edit a non-default setting in a .paths file to work around it -- let it > be tested to the point where we have a collection of regression tests that > we feel cover all of the problem areas -- in particular for grep we need > some pty(1) tests to cover all of the interactive interrupt-laden scenarios > > also, let the -lcmdtst paradigm itself be thouroughly tested > after all, this will be the mechanism for most orgainzation to add their own > builtins > > btw, "thouroughly tested" is not a voting process, ``"worked for me" N times > => its good'' > for ast it implies a good faith effort to supply regression tests that hook > into the build system > which automates the testing grunt work (this was learnt over time -- in > general in ast the > parts that have the most tests are the newer parts -- tests for older parts > happen when they > contribute to bugs or are otherwise updated) > its fairly easy to get a base set of tests to work the first time > its much harder to code software that has no regressions as the environment > around it evolves > > please suffer with what may seem to be a non-ideal interface for the better > good > eventually, if your favorite command migrates from -lcmdtst to -lcmd, > *you won't have to do anything* to take advantage of it it > > I won't explain this position again for the rest of the year > > on that note > > how about chanelling this -lcmd energy to working on a short list of > candiates for -lcmdtst > my first one is ls(1) for practical reasons > it seem that windows8 "power shell" (I think its cmd.exe) has dir builtin, > and apparently > no dir.exe, so debugging the bootstrap uwin env from ksh gets tedious > > _______________________________________________ > ast-users mailing list > [email protected] > https://mailman.research.att.com/mailman/listinfo/ast-users _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
