Pause on console in libmisc/shell detecting terminal size (mvme5500, beatnik)

[Chris Johns]

On 6/1/2024 7:56 am, Peter Dufault wrote:
>> On Jan 5, 2024, at 1:36 PM, Peter Dufault <dufault at hda.com> wrote:
>>
>> I "#if 0"d out the call to "rtems_shell_term_row_column_swapped()" that checks for a broken "tmux" terminal.  That is what sends "\033[>0q" to the console.  I no longer see "0q" on the console but there is still a long pause before the command is executed.
>>
>> Does it make sense to check the shell's terminal for its size before executing every command?  It could be checked once, or the check could be moved into its own command.  Now the shell checks for the terminal size and if it is a "tmux" terminal before it calls every command.
>>
>> The escape sequence does work on gnome-terminal, so I'm not sure what causes the delay. I can investigate that, but question if this
>> should be done in the shell.
> 
> There's a bug detecting the timeout in rtems_shell_term_wait_for().  It does this:
> 
>   int msec = 150;
>   while (msec-- > 0  && str[i] != '\0') {
>     /* Do stuff. */
>     if (nothing_arrived()) {
>        usleep(1000);
>     }
>   }
> 
>   if (msec == 0) {
>     /* BUG when we broke from the loop due to time out msec is -1, not 0. */
>   }
> 
> so if nothing comes in it treats it like it found a match, and for some reason nothing is coming in.
> 
> The "telnetd01" test I'm running doesn't set CONFIGURE_MICROSECONDS_PER_TICK so I think the default is 10000 us.  That means we call usleep(1000) 150 times when no data arrives.  If usleep() delays for one clock tick then that is 150 * .01 or 1.5 seconds.  Since the code times out twice that's three seconds.  Actually it used to timeout in 4.5 seconds before I disabled the call to rtems_shell_term_row_column_swapped() - that function is called even when the calls to get the lines and columns fails.
> 
> I changed the code to use VTIME of 1 (1/10 second, or 100 msec) instead of 0.   That lets TERMIOS do the character arrival timeout instead of using a delay in a loop that resets - essentially duplicating VTIME != 0 VMIN == 0.  Once I did that it times out as I expect in .1 seconds.

Thanks for investigating this and finding a solution. Are you able to post a patch?

> I don't know WHY no characters arrive but I know why it has a long delay.

The 150msec timeout is needed when accessing remote devices on the other side of
the world but it should be 1/10 of a second and then the shall moves on. The
process is only done when the command prompt is painted so it should not
normally be noticeable.

Chris