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
OK. I understand your point. But: Did you realize that some of us have carefully formulated proposals to put grep, od, tr and xargs into libcmd but NOT enable them by default, that means a intentional builtin grep, builtin od, bulitin tr or builtin xargs must be issued before ANY damage may occur? This will limit the possible damage down to the explicit users who explicitly ask for this trouble. > 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 find(1) would be on my wishlist (grep and od are already done). _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
