From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from albert.gnu.ai.mit.edu ([128.52.46.31]) by hawkwind.utcs.toronto.edu with SMTP id <2230>; Wed, 26 May 1993 15:25:23 -0400 Received: from nutrimat.gnu.ai.mit.edu by albert.gnu.ai.mit.edu (5.65/4.0) with SMTP id ; Wed, 26 May 93 15:25:03 -0400 Received: by nutrimat.gnu.ai.mit.edu (15.11/4.0) id ; Wed, 26 May 93 15:25:00 edt Message-Id: <9305261925.AA00414@nutrimat.gnu.ai.mit.edu> From: friedman@gnu.ai.mit.edu (Noah Friedman) Sender: friedman@gnu.ai.mit.edu To: rsalz@osf.org Cc: rc@hawkwind.utcs.toronto.edu, es@hawkwind.utcs.toronto.edu Subject: Re: heirarchical lists, one more time. Reply-To: friedman@gnu.ai.mit.edu In-Reply-To: <9305261825.AA17370@earth.osf.org> (rsalz@osf.org) Date: Wed, 26 May 1993 16:24:58 -0400 >> You could decide never to improve any program once it's written, I guess, >> but I think that would also be an unfortunate choice. > >Yeah, well > - That's why you get source > - That's why you have alpha and beta tests > - Byron and Paul have been VERY good about announcing UI freeze dates I could fix the problem for myself, but I don't think distributing Noah's Own Version of rc will really help solve the general problem. Having N different flavors of the same shell is as bad as having N different flavors of unix. It has the baggage problem I spoke of. Alpha and beta tests don't seem to matter in this case. It was a documented "feature" that no one bothered to fix right the first time. Well, I don't think documenting arbitrary limitations in a program is an acceptable way of handling the problem. The GNU utilities could have compromised by having fixed buffer and line length limits just like most standard unix utilities do only making them larger. But that would have just put off the problem a little longer, and still failed to come through for someone's special case. That is at least one reason why people are using abominations like perl: Larry was very careful not to leave stupid arbitrary limitations in it. Of course, one can criticize that GNU programs are consequently larger and consume more resources, but I don't think this is a serious concern for rc and es because fixing them would consume a negligable amount of resources (namely, a couple more cycles and a few more bytes in the environment for a pathological case). I don't see what the UI has to do with fixing a quoting bug in the environment that you propagate. Who actually uses the particular implementation of array propagation to any particular advantage? I thought this was supposed to be transparent. Let's ask the rc/es user community: Do any of you actually *rely* on the ^A bug? Or do you just figure it'll never hit you? I have enough experience to know that it will hit *me* someday, because I abuse shells and find lots of bugs all the time. I am not suggesting this has to be fixed right this instance with a new release tomorrow, but I am reminding everyone that these problems will be harder to fix later. Since both rc and es are relatively new to the unix world and have comparatively small usage (compared with, say, csh), maintaining interoperability between them is not too painful. It seems like the best thing to do would be to coordinate a future date at which a version of rc and es would both be released simultaneously with this bug fix.