Re: builtins

Re: builtins

[Smarasderagd]

Scott Schwartz <schwartz@bio.cse.psu.edu> writes:
>My $0.02:  if you have echo as a builtin, read deserves the same.

Should it honour escaped newlines the way Bourne shell read does?
Wouldn't it be nice if you could read arrays?  But what we really
want is to generalize all of the hidden goo that reads input until
we can reimplement the main loop as "while () {read a; eval $a}", and
optionally also "echo $a >> $history", and a replacement for - and --
that lets you do structural editing...

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

Oh, I guess that IS where you want to go. :)

Seriously, I don't see any real reason why a quoting function doesn't
make sense, since whatis already does this...

Re: builtins

[Carlo Strozzi]

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. 

builtins

[Scott Schwartz]

My $0.02:  if you have echo as a builtin, read deserves the same.

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.

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