From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Tue, 5 Apr 2011 14:01:05 -0400 To: 9fans@9fans.net Message-ID: <2cd7317662d2f6c8a3fd59e6aca30bc3@ladd.quanstro.net> In-Reply-To: <86ipusd1wr.fsf@cmarib.ramside> References: <86fwpz55nj.fsf@cmarib.ramside> <257867.782e4d7b.wsc0.mx@tumtum.plumbweb.net> <5ddd9deccbea5e8556dfc0c228b63311@ladd.quanstro.net> <86vcythf8h.fsf@cmarib.ramside> <86ipusd1wr.fsf@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Making read(1) an rc(1) builtin? Topicbox-Message-UUID: cad6701e-ead6-11e9-9d60-3106f5b1d025 > > This discussion is interesting. > > > > "rc is not as good a shell as bash because it lacks built-ins that > > make it a good programming language for writing an acme extension" > > > > Did I summarizer it correctly? Once summarized, am I the only one who > > finds it absurd? > > No, I think a statement of the problem would be more like "rc(1) is not > as useful a language as $fill_in_your_favorite_turing_complete_luggage > because it's not Turing complete". You cannot map arbitrary input to > arbitrary output with a program of finite size in pure rc(1). space shuttles are not as useful as cars, because the space shuttle is not d.o.t. approved. that might be true as you've stated the problem, but you do realize that rc is an acronym for run commands? and you do realize that the unix philosophy is all about this sort of encapsulation and modularity, right? the shell by design doesn't have to do everything. i really don't understand why you can't just skip reading the acme events you don't want, or if they're mixed in with important events. write a little filter in c that pushes the ones you don't want back to acme. is the problem here that you are unfamiliar with c and don't want to write that bit? - erik