[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug in select-command
From: |
Chet Ramey |
Subject: |
Re: Bug in select-command |
Date: |
Sun, 25 Jun 2017 13:01:28 -0400 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 |
On 6/24/17 10:46 AM, Eduardo A. Bustamante López wrote:
> I think this is an easier way to reproduce the problem. I have a terminal
> window with the following dimensions:
>
> dualbus@debian:~$ declare -p COLUMNS LINES
> declare -- COLUMNS="191"
> declare -- LINES="49"
>
> dualbus@debian:~$ bash --version | head -n1
> GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)
>
> Running the script in `interactive' mode (which triggers calls to
> `get_new_window_size' through `get_tty_state' when checkwinsize is
> enabled), lays out the options on seven columns:
Yes, bash is actually doing more work here than it should. The reason for
the calls to get_tty_state is if a program terminates prematurely and
leaves the terminal in a state where interactive input is inconvenient
(noecho mode, for example). If bash isn't reading input from the terminal,
this isn't strictly necessary. But for now, it works.
> Whereas running the same script in `non-interactive' mode results in three
> columns.
Yes, there's no reason to worry about tty settings, so the shell relies on
the environment for the value of COLUMNS. If it's not there, or doesn't
have a sane value, select defaults to 80.
> So the trick is to run an external command in foreground. To see why this
> works, read:
> http://git.savannah.gnu.org/cgit/bash.git/tree/jobs.c?h=devel#n3390
Yes, since the point is to protect interactive shell input from badly-
behaved external programs that can modify the terminal settings. The
shell knows what it does to the terminal and how to undo it.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/