From mboxrd@z Thu Jan 1 00:00:00 1970 From: eekee57@fastmail.fm (Ethan Grammatikidis) Date: Mon, 4 Apr 2011 03:02:10 +0100 Subject: [9fans] Making read(1) an rc(1) builtin? In-Reply-To: <257867.782e4d7b.wsc0.mx@tumtum.plumbweb.net> References: <86fwpz55nj.fsf@cmarib.ramside> <257867.782e4d7b.wsc0.mx@tumtum.plumbweb.net> Message-ID: Topicbox-Message-UUID: c74fc68e-ead6-11e9-9d60-3106f5b1d025 On 4 Apr 2011, at 12:41 am, Tristan Plumb wrote: > >> I'm also a bit stumped by the fact that rc(1) doesn't have anything >> analogous to bash(1)'s string parsing operations: ${foo#bar}, >> ${foo##bar}, ${foo%bar}, ${foo%%bar}, or ${foo/bar/baz}. > I could never remember what these did, except the last one. I could never remember what any of these did, except that they are a major reason I'm thankful I hardly have anything to do with bash any more. Cluttering up your working memory with 600 different cryptic ways to do things is stupid when you're trying to solve a hard problem. Spending time and effort learning 600 cryptic ways to get tiny improvements in performance is stupid when you want the machine to reduce your workload. I'd also like to reiterate what pmarin wrote about trying it out first, except I'd say you will be surprised. :) Without dynamic linking, fork() -- or, to put the problem where it actually occurs, exec() -- is not particularly slow at all. > On the other hand, echo -n is a wart. I wonder, does echo '' -n work? > (My plan9 machine is off and far away.) It works very well, doing exactly what it's supposed to, although I vaguely remember having problems with such a feature in Linux many years ago. It does look slightly warty, being an odd argument out, but if you think about it options are always odd arguments.