rc-list - mailing list for the rc(1) shell
 help / 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
Message-ID: <20000512092223.A1008@tango.libero.it> (raw)
In-Reply-To: <20000510003709.7174.qmail@g.bio.cse.psu.edu>

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
          { 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 :-)

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 index

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-09-17 15:56 are there any patches which add ~ expansion to rc Joseph Skinner
1997-09-17 21:56 ` Scott Schwartz
1997-09-17 22:08 ` Mark K. Gardner
1997-09-18 23:26 Chris Siebenmann
     [not found] ` <cks@hawkwind.utcs.toronto.edu>
1992-06-04 10:05   ` $pid malte
1992-11-04 12:45   ` set subtract malte
1992-11-06 12:03   ` rc and signal handlers malte
1997-09-19 17:21   ` are there any patches which add ~ expansion to rc Jeremy Fitzhardinge
2001-10-24  3:25   ` Beta release rc-1.6b3 available Chris Siebenmann
2001-10-24  3:41     ` Scott Schwartz
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
     [not found]   ` <tjg@star.le.ac.uk>
2000-05-08 11:50     ` David Luyer
2002-04-04 10:04     ` rc 1.6 $version Tim Goodwin
2002-04-04 21:42       ` Scott Schwartz
2000-05-08 13:28   ` building rc on QNX4 Carlo Strozzi
     [not found] <tell@cs.unc.edu>
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-12  5:49 builtins Smarasderagd
2001-10-15 13:56 Beta release rc-1.6b3 available Tim Goodwin
2001-10-17 14:13 ` Buggs
2001-10-17 14:34   ` Tim Goodwin
2001-10-17 21:13     ` Buggs
2001-10-23  7:55 ` Carlo Strozzi
2001-10-23 12:44   ` Tim Goodwin
2001-10-23 15:47   ` Markus Friedl
2001-10-23 21:09     ` Carlo Strozzi
     [not found] <sroberts@certicom.com>
2001-10-23 15:55 ` Sam Roberts
2001-10-23 21:14   ` Scott Schwartz
2001-10-23 21:32 Carlo Strozzi
2001-10-24  3:34 ` Chris Siebenmann
2001-10-24  8:04   ` Carlo Strozzi
2002-03-14 22:37 rc 1.6 $version erik quanstrom
2002-03-27 13:27 ` Tim Goodwin
2002-03-27 21:12   ` Carlo Strozzi
2002-03-30 18:43     ` Paul Haahr
2002-03-31 15:13       ` Carlo Strozzi
2002-04-03 14:31       ` Tim Goodwin
2002-04-03 15:06         ` Paul Haahr

Reply instructions:

You may reply publically 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:

* 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 \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

rc-list - mailing list for the rc(1) shell

Archives are clonable: git clone --mirror http://inbox.vuxu.org/rc-list

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/ public-inbox