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

[smiley@zenzebra.mv.com]

roger peppe <rogpeppe@gmail.com> writes:

> when i've needed a "-n safe" version of echo in
> the past, i've used something like this:
>
> fn myecho {echo -n $"* ^ '
> '}

That doesn't work right when (~ $#* 0).  It outputs a rogue space prior
to the newline.  echo, with no arguments, should ouput just a newline.


"Lyndon Nerenberg (VE6BBM/VE7TFX)"  <lyndon@orthanc.ca> writes:

>> (As a side note, if anyone goes into rc(1)'s source to implement any of
>> this, please add a "--" option (or similar) to the "echo" builtin while
>> you're there.
>
> Echo is not a builtin, and for one possible solution see
> /n/sources/contrib/lyndon/echon.c

Ah, you're right; echo isn't a builtin.  I guess echo would be another
big candidate for elevation to "builtin" status, then.

Unfortunately, echon.c doesn't solve the problem either, because it
doesn't output a trailing newline.  The crux of the problem is how to
output "-n" on a line by itself, followed by a newline.  I don't think
it can be done symmetrically without adding another option to echo.  It
can be done by wrapping "echo" in if/switch statement, but that violates
symmetry of invocation.  Ideally, echo would be invokable like:

    $ echo -n $foo # suppress newline
    $ echo -y $foo # force newline
    $ echo $foo    # newline by default


erik quanstrom <quanstro@quanstro.net> writes:

> could you be concrete about your performance problem.
> if you don't have a performance problem, then there's no
> point to optimizing.

I'm trying to write an Acme client in rc(1).  I'd like to avoid spawning
a new read(1) process every time I make a keystroke or click the mouse.
Using multi-line reads wouldn't help much, because interactivity needs
to be maintained.

I'm using rc(1) because the /mnt/acme/%d/events interface is
well-documented (in /sys/doc/acme/acme.ps), but the C code under
/acme/bin/source/ for reading /mnt/acme/%d/events it is definitively
cryptic.  I've managed to peel away the extra layers of code from one of
the simpler Acme clients, in /acme/bin/source/adict/win.c, and am in the
process of creating a general-purpose Acme event parser in C.  The
output of the filter will be in a form easily digestible by scripts, and
would provide a good "skeleton" example of event parsing for other
coders to build upon.  (There doesn't currently appear to be any such
"starter code" under /acme/bin/source or /sys/doc.)

If only Acme put a single extra space immediately prior the first
integer (c0) in it's event messages, this parsing could have been done
almost entirely within rc(1).

I know that using awk(1) is a possibility, but awk(1) still has to
system() every "test -e", just like rc(1) does.  I would use scheme, but
the scheme in fgb's contrib doesn't seem to provide any way of
stat(2)ing path names without resorting to its foreign function
interface.  :(

All combined (forking read/test/echo, forking awk/sed/dd, parsing
/mnt/acme/%d/events, etc.)... this, I think, is why languages like Perl
came into existence and became so popular.  I could definitely write an
Acme event parser in Perl, or even in bash(1).  rc(1) is just a few
small features shy of making it practical to do in rc(1).

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