NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: lib/48821: libedit EL_SETTY doesn't work



On Wed, 21 May 2014 17:55:31 +0900 (JST)
YASUOKA Masahiko <yasuoka%iij.ad.jp@localhost> wrote:
> On Mon, 19 May 2014 13:50:01 +0000 (UTC)
> christos%zoulas.com@localhost (Christos Zoulas) wrote:
>>  While I like the refactoring of all tis duplicated code, the removal
>>  of the conditional setting is undesirable.
> 
> I agree keeping the condition is safer, but I still cann't understand
> what does the condition mean.
> 
>> It is meant to prevent the user for altering the state of the tty
>> from a 3rd party.  Consider using the editor in the shell (which is
>> used in /bin/sh). vi crashes and leaves the tty in non-canonical, no
>> echo mode.
> 
> Yes,
> 
>>  With your change, the changes from vi get immediately reflected in
>>  the editor.
> 
> The code can be simplified like below:
> 
>   tcsetattr(&ts);

sorry, this should be

    tcgetattr(&ts);

>   // ts = the current setting
>   // ex = last termios for cooked mode
>   // ed = last termios for rawmode
> 
>   if (ts != ex && ts != ed) {// the settings is changed by a 3rd party
>      ex = ed = ts;    // adapt the change from the 3rd party
>      ex |= setbits;   // adapt restriction from SETTY
>      ex &= ~clrbits;  // same as above
>      ed |= setbits;   // same as above
>      ed &= ~clrbits;  // same as above
>   }
>   tcsetattr(&ed);     // reflect
> 
> My change was to remove the "if (..." condition.  So the removal of
> the condition doesn't alter the behavior of "the changes from vi"
> case.
> 
> But it alters the case in which the tty setting isn't changed.  In
> that case, I think executing the conditional block isn't a problem,
> since 'ts' is clean (because it's unchanged) and adapting the
> restriction should be ok.


Home | Main Index | Thread Index | Old Index