rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: friedman@gnu.ai.mit.edu (Noah Friedman)
To: rsalz@osf.org
Cc: rc@hawkwind.utcs.toronto.edu, es@hawkwind.utcs.toronto.edu
Subject: Re: heirarchical lists, one more time.
Date: Wed, 26 May 1993 16:24:58 -0400	[thread overview]
Message-ID: <9305261925.AA00414@nutrimat.gnu.ai.mit.edu> (raw)
In-Reply-To: <9305261825.AA17370@earth.osf.org> (rsalz@osf.org)

>> 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. 


      reply	other threads:[~1993-05-26 19:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-05-26 18:25 rsalz
1993-05-26 20:24 ` Noah Friedman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9305261925.AA00414@nutrimat.gnu.ai.mit.edu \
    --to=friedman@gnu.ai.mit.edu \
    --cc=es@hawkwind.utcs.toronto.edu \
    --cc=rc@hawkwind.utcs.toronto.edu \
    --cc=rsalz@osf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).