From mboxrd@z Thu Jan 1 00:00:00 1970 From: smiley@zenzebra.mv.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <86fwpz55nj.fsf@cmarib.ramside> <257867.782e4d7b.wsc0.mx@tumtum.plumbweb.net> <5ddd9deccbea5e8556dfc0c228b63311@ladd.quanstro.net> Date: Mon, 4 Apr 2011 21:35:26 +0000 In-Reply-To: (roger peppe's message of "Mon, 4 Apr 2011 10:26:39 +0100") Message-ID: <86vcythf8h.fsf@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [9fans] Making read(1) an rc(1) builtin? Topicbox-Message-UUID: c87f2ea0-ead6-11e9-9d60-3106f5b1d025 roger peppe 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)" 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 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| +---------------------------------------------------------------+