On 13 June 2012 18:00, Glenn Fowler <[email protected]> wrote: > > On Wed, 13 Jun 2012 16:36:32 +0200 Dan Shelton wrote: >> On 13 June 2012 15:43, Glenn Fowler <[email protected]> wrote: > >> > 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. > > dgk had discussed these issues privately before they were proposed > I can't count how many times a simple change has come back to bite us > (this includes linking in code that is not even used -- there are many > large legacy projects that make it very hard to remove code, even if it is > dead by 100 different ways of looking at it, because of unintended > consequences) > we decided to err on the side of caution > especially where the integrity of ksh is involved > with the current solution all control is limited to the .paths file > when diagnosing problems we can say "remove the .paths file" and > be reasonably certain that -lcmdtst is out of scope > > we also wanted to limit the number and types of ksh versions in the field > e.g., to avoid > "replace ksh YYYY-MM-DD immediately because there is a security bug in > xargs" > > lets get ksh stability against the great debugging that has been going on in > the > past few months (valgrind, bleeding edge gcc options, bleeding edge non-gcc > builds) > and separately, stability in -lcmdtst > and then revisit -lcmdtst::foo => -lcmd:foo
OKOK, I got it. One request: Could you please ship cmdtst with ast-ksh? ast-open doesn't build on some platforms with stock installations and it is hard to install extra stuff just to get ast-open to compile _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
