[RFC, PATCH] new applet resize [was: Re: How do I get vi to know my window size?]

[Rob Landley]

On Sunday 24 September 2006 2:18 pm, Bernhard Fischer wrote:
> On Thu, Sep 21, 2006 at 10:55:43PM -0400, Rob Landley wrote:
> >On Thursday 21 September 2006 4:17 pm, Bernhard Fischer wrote:
> >> Rob, do we want this applied after somebody quickly checked that it's
> >> doing what it is supposed to do?
> >
> >I don't, no.
> 
> Noted.
> 
> >              What's wrong with having bbsh do this again?
> 
> Not everyone will use that currently non-existing so called "bbsh".

Not everyone will use BusyBox, either.

> Don't forget the users that will run any other non-busybox provided
> shell and still want to use busybox's coreutils or console-utils
> replacements.

Sure.  And resize is part of x11.  Are we bolting bits of that onto BusyBox 
now?

> The mythical bbsh may be (still don't see why it is concerned about it,
> but i know nothing about shells)

And yet you're complaining I'm not letting you help develop it.

For your information, the shell is already concerned because it has to set 
$LINES and $COLUMNS, and reset them when it gets SIGWINCH.  It also needs to 
know how wide the screen is in order to know when it hits the left edge of 
the screen during backspace, because for some reason your average unix TTY 
doesn't back up to the end of the previous line so you have to cursor up and 
jump to EOL yourself, and know when to do it.

The first report I got about this problem was from somebody upset that the 
shell's backspace thing wasn't working right:
http://www.busybox.net/lists/busybox/2006-June/022794.html

I already mentioned that reliably using a probing method that performs in-band 
signaling (which the ANSI query does) requires fairly careful setup.  Or, you 
can simply not care about reliability at all, and wait for the next round of 
bug reports from somebody who put it in their /etc/profile and can't figure 
out why it's causing problems.

> Also, having "bbsh" be a user would help in no way if a user decided not
> to use it (and not to use bbsh's reimplementation of uudecode et al for
> that matter).
> Do you imply that you will rip out all of coreutils, findutils,
> modutils, networking etc since you plan to write a shell that does
> potentiall use them?!

No, but this would be the first x11 utility we'd added to the thing.  At what 
point do we suck in xvidtune?  (Congratulations, you just convinced me that 
it probably shouldn't go in.)

> No idea what you're referring to. The only change i recently saw that
> was checked into shell/bbsh.c was reverting vda's attempt to touch
> bbsh.c:

My copy's had a couple weeks of development since then (although I'd planned 
to spend last week on it and wound up dealing with Bruce instead, and didn't 
get to spend any of this weekend on it because I was so backlogged with other 
things.  But I do get some stuff done during the week.)

> I.e you did NOT put anything at all into bbsh yesterday (22th Sep 2006
> or the like).

I put it into my copy, on my laptop.  I haven't checked the copy on my laptop 
in yet because it contains large chunks of code that don't currently work as 
intended.

> While you said this when i dared to send you some *comments* WRT the
> current source of bbsh that is in the tree:

You yourself just said you know nothing about shells.  Was this incorrect?

We currently have four other shells in the tree.  They've been there years, 
and haven't significantly been cleaned up or unified before I started doing 
it myself.  (There was at least one major previous attempt, which is how we 
got the fourth shell.)

I'm trying to write a new shell that solves a large number of interconnected 
problems with a small amount of code, and this requires extensive thought 
about how to go about it up front.  Just getting the _parsing_ right is very 
much nontrivial.  I've been studying this problem for a _year_ now, and I'm 
still struggling with large chunks of it.  You want to help _without_ first 
studying the problem, simply by commenting on what I've done.

Rob
-- 
Never bet against the cheap plastic solution.