Redirecting stderr changes the output of tput but only when capturing the output to a variable?

Question

I'm trying to get the width of the current terminal window in a script and use 80 as a fallback in case that isn't possible. I thought that's pretty simple:

cols=$( tput cols || echo 80 ) ; echo $cols
# -> 100

100 is correct, I made the terminal 100 chars wide. As cols is no POSIX conform argument to tput, not all systems will support it, thus the fallback. Now let's test the fallback:

cols=$( tput colsx || echo 80 ) ; echo $cols
# -> tput: unknown terminfo capability 'colsx'
# -> 80

Hmmmm... not so nice. I don't want to see that error. It's printed on stderr, so let's just suppress it:

cols=$( tput colsx 2>/dev/null || echo 80 ) ; echo $cols
# -> 80

Yes, that's much better. So the final code is

cols=$( tput cols 2>/dev/null || echo 80 ) ; echo $cols 
# -> 80

80? WTF? Why does it run into the fallback now? Let's try this:

cols=$( tput cols 2>/dev/null ) ; echo $cols  
# -> 80

Ahhhh... redirecting stderr changes the output of tput? How's that possible? Let's confirm that:

tput cols 2>/dev/null
# -> 100

Okay, now I'm lost! Can someone please explain me what's going on here?

Answer 1

There's a partial answer here

tput cols can lead to data from different sources based on these cases:

• one of fd 1,2 is a tty
• both fd 1,2 are not a tty

When running tput cols : terminal setting columns may be fetched with an ioctl() using fd 1,2 if possible, otherwise get terminfo capability cols.

This session sets 99 for terminal columns,

$ stty columns 99; stty -a | grep columns
        speed 38400 baud; rows 24; columns 99; line = 0;

Only fd 1 redirected (to a non-tty):

$ tput cols > out; cat out
99

Only fd 2 redirected:

$ tput cols 2> err; wc -c err
99
0 err

Both fd 1,2 redirected:

$ tput cols > out 2>&1; cat out
80

fd 1 not a tty:

$ echo $(tput cols || echo 100)
99

fd 1,2 not a tty:

$ echo $(tput cols 2> /dev/null || echo 100)
80

To show cols cabability being fetched when fd 1,2 are redirected, a terminfo named tmp with different cols was created and installed, then:

$ export TERM=tmp TERMINFO=$HOME/.ti
$ infocmp | grep cols
        colors#8, cols#132, it#8, lines#24, pairs#64,

fd 1,2 not a tty:

$ echo $(tput cols 2> /dev/null || echo 100)
132

fake cap, tput exits non-zero:

$ echo $(tput kol 2> /dev/null || echo 100)
100

Answer 2

Actually the answer of Milag solves the riddle! Well, it's a bit complicated and the real answer is a bit hidden within all details given there, so I'm providing a simpler to understand reply here for the interested reader, yet kudos goes to Milag, thus I will accept this answer (also for the reputation).

In simple words, here is what's going on:

tput cols requires a tty to get the real terminal width. When I open a terminal window, both stdout and stderr are ttys, thus

tput cols

prints a correct result. If I now redirect stderr to /dev/null, as in

tput cols 2>/dev/null

then stderr is no longer a tty, it is a char file. Yet this is no problem, as stdout is still a tty.

However, if I capture the output in a variable, as in

cols=$( tput cols 2>/dev/null )

stdout is no tty either any longer, it is a pipe to the shell which captures the output of the command. Now tput has no tty at all anymore and thus cannot obtain the real width any longer, so it uses some fallback and this fallback reports 80 on my system (other systems may have better fallback mechanisms and still report the correct value).

So for my script, I will have to work around this issue a bit:

if tput cols >/dev/null 2>&1; then
    cols=$( tput cols )
else
    cols=80
fi

The first if checks if tput knows the cols argument, without producing any visible output at all or capturing anything, I just want to know what the exit code is. If it does support this argument, I capture the output, otherwise I use the fallback directly.