Re: Gettings LINES and COLUMNS from stderr instead of /dev/tty

2022-07-18 Thread Martin Schulte
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

2022-07-18 Thread Chet Ramey

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

2022-07-17 Thread Martin Schulte
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

2022-07-16 Thread Dale R. Worley
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

2022-07-16 Thread Martin Schulte
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