Donc, je travaille sur un script et j'ai trouvé un comportement étrange. Je suis sûr qu'il existe une explication logique au fait que la sortie des 4 e et 6 e lignes de commande est différente de celle des autres cas, mais je ne parviens pas à le trouver.
1 $ tput cols
128
2 $ tput cols 2>/dev/null
128
3 $ echo $(tput cols)
128
4 $ echo $(tput cols 2>/dev/null)
80
5 $ (tput cols >/tmp/cols.txt); cat /tmp/cols.txt
128
6 $ (tput cols &>/tmp/cols.txt); cat /tmp/cols.txt
80
7 $ echo $(tput cols 2>/dev/null; echo $COLUMNS; tput cols)
80 128 128
Pourquoi la redirection stderr modifie-t-elle la sortie de tput dans un sous-shell?
Finalement, je veux faire quelque chose comme ça dans mon script pour le faire fonctionner sur des systèmes où tput / ncurses n'est pas disponible:
cols=$(tput cols 2>/dev/null || echo $COLUMNS)
L'exemple ci-dessus a été créé avec Bash 4.3.46 (1) -release et ncurses 6.0.20150627
Réponses:
Selon
strace
, cela se produit cartput
uniquement les tentatives de lecture des paramètres tty à partir de ses sorties stdout et stderr (fd 1 et 2). Puisque vous avez explicitement redirigé stderr, et$( )
redirige également stdout, tput abandonne.La meilleure solution consisterait à appliquer une correction à tput afin de vérifier également la présence d'un terminal dans stdin ; Cependant, vous pouvez également simplement supprimer la
2>/dev/null
redirection, cartput cols
ne génère jamais de message d'erreur. (Et si cela produisait des messages d'erreur, mieux vaut y faire attention.)la source