Re: Gettings LINES and COLUMNS from stderr instead of /dev/tty
Hello Chet, on 2022-07-18 10:26:05 -0400 you wrote: > On 7/16/22 11:18 AM, Martin Schulte wrote: > > Hello, > > > > I'm just wondering that bash (reproduced with 5.2-rc1 under Debian 11) > > seems to determine LINES and COLUMNS from stderr. > > ... > When it's not interactive, all bets are off, and stderr is usually > a safe default. There's no consistent approach across shells. At least I lost my bet ;-) Since I still have the opinion that either stdout or /dev/tty should be asked to set the variables (because it's the "natural assumption" that you want to format what you write there) please consider the following script: #!/bin/bash shopt -s checkwinsize ( : ) # set LINES/COLUMNS for first time while true; do if ((EPOCHSECONDS%86400==11655)); then printf -v msg '%S' "It's pi o'clock UTC" else printf -v msg '%(%T)T' $EPOCHSECONDS fi tput clear ; tput cup 0 $(((COLUMNS-${#msg})/2)) ; echo "$msg" sleep 1 done It fails with a "bash: printf: `S': invalid format character" once a day but I've no chance to catch this error - either it is cleared on the screen or logging stderr breaks the output. BTW: tput first tries stderr, then stdout, then stdin, then /dev/tty. Best regards Martin
Re: Gettings LINES and COLUMNS from stderr instead of /dev/tty
On 7/16/22 11:18 AM, Martin Schulte wrote: Hello, I'm just wondering that bash (reproduced with 5.2-rc1 under Debian 11) seems to determine LINES and COLUMNS from stderr. It uses stderr because if the shell is interactive, stderr is guaranteed to be a terminal, and that's the file descriptor it uses to perform job control. When it's not interactive, all bets are off, and stderr is usually a safe default. There's no consistent approach across shells. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Gettings LINES and COLUMNS from stderr instead of /dev/tty
Hello Dale! > Martin Schulte writes: > > I'm just wondering that bash (reproduced with 5.2-rc1 under Debian 11) > > seems to determine LINES and COLUMNS from stderr. > > It's not clear to me that the manual page says where the LINES and > COLUMNS values are obtained from. Sorry, maybe my mail was somewhat too short... I didn't find anything in the man pages that states where these variables are obtained from. To show the behaviour do the following: - Open a (resizable) terminal window (with a bash in it), say it is /dev/pts/5 - In a second terminal window start the script #!/bin/bash shopt -s checkwinsize trap 'echo $LINES $COLUMNS' SIGWINCH while true; do sleep 0.1; done with ./winsize 2> /dev/pts/5 Whenn you now resize this window, the script will show you the size of the other one. The sources (get_new_windows_size in lib/sh/winsize.c) seem to explain well why this happens. Hope this helps to understand the problem! Best regards Martin
Re: Gettings LINES and COLUMNS from stderr instead of /dev/tty
Martin Schulte writes: > I'm just wondering that bash (reproduced with 5.2-rc1 under Debian 11) > seems to determine LINES and COLUMNS from stderr. It's not clear to me that the manual page says where the LINES and COLUMNS values are obtained from. Dale
Gettings LINES and COLUMNS from stderr instead of /dev/tty
Hello, I'm just wondering that bash (reproduced with 5.2-rc1 under Debian 11) seems to determine LINES and COLUMNS from stderr. For example, this will lead to strange results when starting the script #!/bin/bash shopt -s checkwinsize trap 'echo $LINES $COLUMNS' SIGWINCH while true; do sleep 0.1; done with standard error redirected to a file (or - even more strange ;-) - another terminal). A quick POC shows that replacing tty = input_tty (); with tty = open( "/dev/tty", O_RDONLY ); in get_new_windows_size in lib/sh/winsize.c gives the "expected" result. In case there is some reason not to use /dev/tty, wouldn't it then be better to ask stdin instead of stderr? The script will most probably be interested in the size of device it is writing to, not the one it is logging to. Best regards Martin