rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: Carlo Strozzi <carlos@linux.it>
To: rc@hawkwind.utcs.toronto.edu
Subject: Re: builtins
Date: Fri, 12 May 2000 03:22:23 -0400	[thread overview]
Message-ID: <20000512092223.A1008@tango.libero.it> (raw)
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

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. 


  reply	other threads:[~2000-05-14  5:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <sroberts@uniserve.com>
2000-04-26 15:02 ` building rc on QNX4 Sam Roberts
2000-04-27 16:56   ` Scott Schwartz
2000-04-27 20:41     ` Sam Roberts
2000-04-28  7:28       ` vrl (was: Re: building rc on QNX4) Gert-Jan Vons
2000-04-28 18:38         ` Sam Roberts
2000-05-02  8:16           ` Gert-Jan Vons
2000-04-28 19:03         ` rc not session leader? Sam Roberts
2000-04-27 17:39   ` building rc on QNX4 Carlo Strozzi
2000-05-02 14:41     ` Tim Goodwin
2000-05-04 15:18       ` Carlo Strozzi
2000-05-08  8:29         ` Tim Goodwin
2000-05-08  8:58           ` Chris Siebenmann
2000-05-08  9:15             ` Tim Goodwin
2000-05-08 23:25               ` Stephen Tell
2000-05-10  0:37                 ` builtins Scott Schwartz
2000-05-12  7:22                   ` Carlo Strozzi [this message]
2000-05-08 11:50           ` building rc on QNX4 David Luyer
2000-05-08 13:28           ` Carlo Strozzi
2000-05-12  5:49 builtins Smarasderagd

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=20000512092223.A1008@tango.libero.it \
    --to=carlos@linux.it \
    --cc=carlos@texne.com \
    --cc=rc@hawkwind.utcs.toronto.edu \
    /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).