script crashes when "width" variable is not defined

[lectrode]

$ yes|sudo apacman -Su
stty: 'standard input': Inappropriate ioctl for device
:: Starting full system upgrade...
 there is nothing to do
:: Synchronizing aur database...
stty: 'standard input': Inappropriate ioctl for device
/usr/sbin/apacman: line 576: *6/10: syntax error: operand expected (error token is "*6/10")

This is caused by an incompatibility between the stty command, and pipes / background processing (basically without /dev/stdin), resulting in a crash when the script is run non-interactively.

There are 2 instances of stty in apacman:
line 115: _WIDTH="$(stty size | cut -d ' ' -f 2)"
line 574: width="$(stty size)"

This error can be avoided by using a compatibility layer, which can ensure that these variables are defined by assigning a (relatively common) static value like 80 if the variable is not defined:

proposed line 115:

_WIDTH="$(stty size | cut -d ' ' -f 2)"
_WIDTH="${_WIDTH:-80}"

proposed line 574:

width="$(stty size)"
width="${width:-80}"

The 2nd line of each defines the variable if it has not been defined. That ensures that the variable is always defined and prevents the script from crashing when it is not available.

I think this is a bug that was only made evident by commit 6925270 . Before that commit, the width variable was only used in barchars="$(($width-51-7))". when it wasn't defined, -51 was still a valid number and the overall expression was still valid. When that changed to infolen="$(($width*6/10))", that exposed this bug as *6 is not a number and the expression is invalid.

I really appreciate the time and effort put into this script. It is by far the easiest to use and just about the only one that allows AUR installs when run with root permissions, which is very much needed for semi-automatic remote management. Let me know if there's anything I can do to help resolve this issue.

Software versions

Apacman: v3.1
Pacman: v5.0.1

[lectrode]

Is there anything that can be done to esure the width variable is defined before using it in an expression? That's all that really needs to be done to resolve this issue.