* Re: builtins @ 2000-05-12 5:49 Smarasderagd 0 siblings, 0 replies; 3+ messages in thread From: Smarasderagd @ 2000-05-12 5:49 UTC (permalink / raw) To: rc, schwartz 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... ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <tell@cs.unc.edu>]
* Re: building rc on QNX4 @ 2000-05-08 23:25 ` Stephen Tell 2000-05-10 0:37 ` builtins Scott Schwartz 0 siblings, 1 reply; 3+ messages in thread From: Stephen Tell @ 2000-05-08 23:25 UTC (permalink / raw) To: rc On Mon, 8 May 2000, Tim Goodwin wrote: > Date: Mon, 8 May 2000 05:15:01 -0400 > From: Tim Goodwin <tjg@star.le.ac.uk> > To: rc@hawkwind.utcs.toronto.edu > Subject: Re: building rc on QNX4 > > > In order to make this work, you need to find a utility that is > > guaranteed to read no more than the first line of standard input. > > Yup. What if such a utility were distributed with rc, or as part of an > rc-utils package? I suppose that would be sufficient. The workaround I've used has been this: var = `{sh -c 'read t; echo $t'} # read var Starting up sh just to avoid the little bit of code that a read builtin would add to rc itself or an included utility seems a bit rediculous. -- Steve Tell | tell@cs.unc.edu | http://www.cs.unc.edu/~tell | KF4ZPF On Leave from UNC working at Chip2Chip, Inc. tell@chip2chip.com/919-929-0991 ^ permalink raw reply [flat|nested] 3+ messages in thread
* builtins 2000-05-08 23:25 ` building rc on QNX4 Stephen Tell @ 2000-05-10 0:37 ` Scott Schwartz 2000-05-12 7:22 ` builtins Carlo Strozzi 0 siblings, 1 reply; 3+ messages in thread From: Scott Schwartz @ 2000-05-10 0:37 UTC (permalink / raw) To: rc 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. :-) ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: builtins 2000-05-10 0:37 ` builtins Scott Schwartz @ 2000-05-12 7:22 ` Carlo Strozzi 0 siblings, 0 replies; 3+ messages in thread From: Carlo Strozzi @ 2000-05-12 7:22 UTC (permalink / raw) To: rc 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2000-05-14 5:34 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2000-05-12 5:49 builtins Smarasderagd [not found] <tell@cs.unc.edu> 2000-05-08 23:25 ` building rc on QNX4 Stephen Tell 2000-05-10 0:37 ` builtins Scott Schwartz 2000-05-12 7:22 ` builtins Carlo Strozzi
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).