Re: [9fans] Making read(1) an rc(1) builtin?

[smiley@zenzebra.mv.com]

Lyndon Nerenberg <lyndon@orthanc.ca> writes:

>> Unfortunately, echon.c doesn't solve the problem either, because it
>> doesn't output a trailing newline.
>
> That's the whole point.  'echon' replaces 'echo -n ...', then echo.c
> loses all knowledge of any option flags.

Oh.  So there's another version of "echo", too?  I didn't know that.

/me pulls up lyndon's contrib again...

Hm.  I don't see an "echo.c" in there.

But anyway, yes, splitting "echo" and "echo -n" into two commands would
solve the problem in a symmetric way.


ron minnich <rminnich@gmail.com> writes:

> 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).
Developing an Acme client is just, historically, how I came to that
discovery (and to my subsequent frustration with rc's feature set).

I think string parsing and numeric comparisons are reasonable features
to include in almost any programming language.  I think having
primitives for line-oriented input and line-oriented output are more
than appropriate for a line-oriented language like rc(1).  As it stands,
rc(1) can have it's cake, but it can't eat it without a fork(2).

--
+---------------------------------------------------------------+
|E-Mail: smiley@zenzebra.mv.com             PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA  3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+