roger peppe <rogpe...@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)" <lyn...@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 <quans...@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: smi...@zenzebra.mv.com PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B|
+---------------------------------------------------------------+
