[PATCH] vi: discover window size even on serial consoles

Denys Vlasenko vda.linux at googlemail.com
Tue Apr 27 07:07:19 UTC 2010


On Tuesday 27 April 2010 07:31, Rob Landley wrote:
> On Monday 26 April 2010 07:36:59 Denys Vlasenko wrote:
> > On Thu, Apr 22, 2010 at 6:39 AM, Rob Landley <rob at landley.net> wrote:
> > > Admittedly a specific narrow race condition in the pattern of user input
> > > (not the cat stuff above which would be inputting data while the prompt
> > > printed) can type something like "x" "enter" and have a spurious escape
> > > sequence fed to x. But the same is true if you typo a key like "cursor
> > > up" after hitting enter. Not the end of the world.
> >
> > The race is not narrow at all.
> >
> > "sleep 1; ash" + hold down [Enter] is quite an easy way to make ash emit
> > the "where is cursor" sequence, then see '\n' on input,
> 
> Not if ash peeks the input before emitting the sequence, and only emits the 
> sequence when there's no pending input.

Yes. It tests for that. Sometimes there is really no input.
Sometimes '\n' comes in exactly after than check. I've seen in many times.

> We know how to do this because the VI  
> escape sequence parsing code currently does a time-sensitive peek for escape 
> sequence assembly.  It behaves differently when input is waiting vs when no 
> input is waiting.
> 
> So if they start typing during the sleep 1, then the input is buffered and 
> waiting as soon as ash starts looking for it.  So the race only happens when 
> they produce _new_ input between the time ash emits the sequence and the time 
> ash reads back the result, and it only matters if that input includes a 
> newline, and if _all_ they typed is a newline then it's a blank line and ash 
> gets control back immediately.  That's the "narrow window" I was referring to.

"Narrow window" for me means "it's so hard to hit it's not a problem in practice".
In this case, it is relatively easy to hit.

-- 
vda


More information about the busybox mailing list