From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp1.libero.it ([193.70.192.51]) by hawkwind.utcs.toronto.edu with SMTP id <26172>; Sun, 14 May 2000 01:34:23 -0400
Received: from LocalHost (151.15.149.196) by smtp1.libero.it; 12 May 2000 09:40:40 +0200
Received: from carlos by localhost with local (Exim 2.05 #1 (Debian))
	id 12q9mB-0000Mh-00; Fri, 12 May 2000 09:22:23 +0200
Date:	Fri, 12 May 2000 03:22:23 -0400
From:	Carlo Strozzi <carlos@linux.it>
To:	rc@hawkwind.utcs.toronto.edu
Subject: Re: builtins
Message-ID: <20000512092223.A1008@tango.libero.it>
Reply-To: carlos@texne.com
Mail-Followup-To: rc@hawkwind.utcs.toronto.edu
References: <tell@cs.unc.edu> <20000510003709.7174.qmail@g.bio.cse.psu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <20000510003709.7174.qmail@g.bio.cse.psu.edu>; from schwartz@bio.cse.psu.edu on Tue, May 09, 2000 at 08:37:09PM -0400
Organization: TeXne.COM

On Tue, May 09, 2000 at 08:37:09PM -0400, Scott Schwartz wrote:
| My $0.02:  if you have echo as a builtin, read deserves the same.

I definitely agree. This is the single most important point IMHO.
The prolem isn't just reading one single line fron stdin, as many unix
utilities would allow that easily, but rather to make possible a construct
like:
          { while ( read a ) echo $a } <file

where 'file' is big enough to blow up the environment if swallowed
all in one go.

Just as a hint, bourne shells solve the problem by silently forking a
subshell to handle the above -- and using a builtin read, of course.

| 
| My other $0.02:  echo needs a sibling builtin, quote, to enquote it's
| arguments so that they can be read by the shell.  Lisp got that right ages
| ago.  Inferno got it right more recently.

I'm not quite sure I am understanding this ...

| 
| Followups to the es list, I guess. :-)

Well, I think the 'read' stuff pertains also to Rc. While we are at it,
I am one of those who rised also the 'export or not to export' issue.
Having a shell that exports everything by default does pose some
problems.  I use the shell to build the "outer frame" of relatively
complex Web sites (search engines, on-line auctions, ...), and I came
to pick the shell for that job after having tried every sort of other
languages, from perl to tcl, to C, to ... you name it. As chance
would have it that the Apache Web server passes an almost completely
empty environment to CGI programs, to make it harder to trick them
into doing wrong things by fiddling with env stuff. Having a shell
that allows not to have everything global by default would help a lot
with building large applications, where the possibility of de-coupling
things may be a critical factor.

Maybe an all-or-none approach would solve both the need of not exporting
and the need of not breaking backward compatibility, and it would also be
be more in-line with the clean design of Rc, which is what I like most.
Beside having a @{...} construct to run things in a subshell, we could have
also a %{...} thing (or whatever), that would pass a completely empty
environment to subprocessess. Something like 'env -', but without spawning
an extra- process. In this way it would be applicable also when calling
functions.  Does that make any sense to you ?

Apart from that, I do not think Rc needs any other stuff built-in. It is
one of the best examples of perfectly usable minimalism I've seen so far :-)

        --Carlo
-- 
I can read MIME or uuencoded e-mail attachments in PDF, Postscript, HTML,
RTF or text formats. Please do not send Word or Excel files.