[Toybox] Editors and such.

[Rob Landley]

On 07/01/2012 01:13 AM, David Seikel wrote:
> On Sat, 30 Jun 2012 20:02:55 -0500 Rob Landley <rob at landley.net> wrote:
> 
>> On 06/30/2012 07:01 PM, David Seikel wrote:
>>
>>>  Oh yeah, my infrastructure is aiming
>>> at sed to.  All fairly similar at the basic level anyway.
>>
>> What does interactive line editing have to do with sed, a line-by-line
>> regex stream processor I previously wrote the busybox implementation
>> of?
>>
>> Just wondering.
> 
> I'm writing generic text editing functions.  They don't care if it's a
> full screen editor, line editor, or stream editor driving them, they do
> text editing.  Ed, ex, vi, and sed all have "select lines with a regex,
> do some editing function on them".  Lots of other things they have in
> common to.  Including the ability to run "scripts" of their own
> commands over text.

So you're writing command line history infrastructure for shells.

And you're writing the pluming behind "more" and "less".

And you're writing the plumbing behind sed.

And you're writing vi, but it's also going to do emacs and joe and ex
and ed.

And you're writing scripting infrastructure.

And you're writing midnight commander.

And it's all one big thing which you're going to deliver all at once in
a giant patchbomb.

Good luck?

> I read through the relevant standards and compiled lists of what they
> do that is common, and what they do that is not so common.  Did the
> same with the documentation for joe, microemacs, nano, and midnight
> commanders editor.  Also included more, less, and readline.
> 
> Not gonna be all things for all people, but there's enough common stuff
> for generalization to work out for us.

I'm adding a chunk at a time and checking it in. I have somewhat
elaborate plans, but they change as I go along.

Your design of course takes into account none of _my_ elaborate plans,
but since I haven't checked them in yet they're fair game.

But I'm a bit nervous about impedence matching a giant code drop.

> The toybox sed (as of 0.3.0) is a stub with "hello world" in it.

What I've checked in is, yes.

> None
> of the others have been written yet.  I think my stuff could be useful
> to them all, and toysh as well (readline type stuff).

I have yet to see, let alone review, a line of code from this.

I still have pending todo items from Elie and Georgi, which I'd be
working on if I hadn't gotten distracted into working on od.

Speaking of od, more notes on that:

-j has to support non-seekable input, such as pipes (cat | od -j 123).

What does -j do when you have multiple files? Ah, _concatenated_ input
files. So xlseek() is wrong on multiple counts: because if seek fails
you need to fall back to read(), and because you may skip more than one
entire input file. And this can't be "skip input blocks" because the
skip isn't required to be block aligned.

If the output of od gets dropped (-EPIPE), what happens? Should it retry
short writes, which implies xprintf() should do an xmprintf() into a
malloc buffer and then do a writeall() on it, although I really am
trying to get automatic retry in there with sigaction(SA_RESTART) but
that doesn't protect you against _short_ writes, just spurious zero
length writes, and yes you can get that with "cat | cat" when you kill
-STOP and then kill -CONT them...

Really?  -A defaults to _octal_? The spec doesn't say (explicitly says
the default is undefined) but the gnu/dammit one does and busybox picked
it up from that, so...

Currently trying to figure out when I should I increment the error exit
return code. (I.E. what corner cases count as an error...)


Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

 1341161885.0