functions.sh uses tput for handling of color output. However, for ENDCOL the escape sequences are hardcoded, so dumb terminals will see escape sequences that they don't understand.
Created attachment 496186 [details, diff] [PATCH] functions.sh: Don't hardcode escape seqences for ENDCOL. Attached patch fixes the problem for me.
Still need this?
(In reply to Sam James from comment #2) > Still need this? Seriously? :( The patch still applies cleanly, 5 years and 4 releases later. So what is blocking this?
(In reply to Ulrich Müller from comment #3) > (In reply to Sam James from comment #2) > > Still need this? > > Seriously? :( > > The patch still applies cleanly, 5 years and 4 releases later. So what is > blocking this? That's why I'm asking you? I just wanted to check it's still relevant before I push it? I could've just ignored it but I obviously want to get this fixed.
It is still relevant, and I don't understand the reason for the long delay.
(In reply to Ulrich Müller from comment #5) > It is still relevant, and I don't understand the reason for the long delay. Thanks for confirming. I don't know why but I wasn't a developer 5 years ago. I didn't want to just commit a patch in case the bug was outdated or something. Don't shoot the messenger :)
(In reply to Ulrich Müller from comment #1) > Created attachment 496186 [details, diff] [details, diff] > [PATCH] functions.sh: Don't hardcode escape seqences for ENDCOL. Signed-off-by: Ulrich Müller <ulm@gentoo.org>
Created attachment 795604 [details, diff] functions.sh: Don't hardcode escape seqences for ENDCOL
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gentoo-functions.git/commit/?id=44c2ebb24e53bbf8c8848072cbe3b66471f883df commit 44c2ebb24e53bbf8c8848072cbe3b66471f883df Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2017-09-23 18:38:29 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-07-30 05:46:33 +0000 functions.sh: Don't hardcode escape seqences for ENDCOL Similar to handling of colors, this should make use of tput, rather than sending unknown escape sequences to dumb terminals. Bug: https://bugs.gentoo.org/631870 Signed-off-by: Ulrich Müller <ulm@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> functions.sh | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6dfa7a4f87b4dd39c4d3c15d46b3f236bfe2b87e commit 6dfa7a4f87b4dd39c4d3c15d46b3f236bfe2b87e Author: Sam James <sam@gentoo.org> AuthorDate: 2022-07-30 05:49:12 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-07-30 05:57:26 +0000 sys-apps/gentoo-functions: add 0.17 Closes: https://bugs.gentoo.org/631870 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/gentoo-functions/Manifest | 1 + .../gentoo-functions/gentoo-functions-0.17.ebuild | 27 ++++++++++++++++++++++ 2 files changed, 28 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gentoo-functions.git/commit/?id=eb36c3077fd69b7cbc5ef64c68d42baff50b3d43 commit eb36c3077fd69b7cbc5ef64c68d42baff50b3d43 Author: Kerin Millar <kfm@plushkava.net> AuthorDate: 2023-02-15 07:02:48 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-02-15 07:32:45 +0000 Implement proper TTY detection, once and for all Following a litany of ill-considered bodges and hacks over the years, it is high time that the matter of tty detection was conclusively dealt with. This commit aims to accomplish exactly that, in a fashion that can be described twofold. Firstly, the recently introduced _eprint() function will now test whether STDOUT is a tty at the time of invocation. If found to be a tty, ECMA-48 SGR sequences shall be incorporated into the message. Otherwise, they shall not be. This positively affects the following functions. - ebegin - einfo - einfon - eerror - eerrorn - ewarnn - ewarn - vebegin - veinfo - veinfon - veerror - veerrorn - vewarnn - vewarn Note that the *eerror* and *ewarn* functions duplicate file descriptor 2 (STDERR) to file descriptor 1 (STDOUT), meaning that the -t 1 test will always be in the context of the appropriate file descriptor. Secondly, the _eend() function will now test whether STDOUT is a tty at the time of invocation. Just as with _eprint(), ECMA-48 SGR sequences will be omitted in the case that STDOUT is found not to be a tty However, the fact that _eend() prints a so-called end column must also be taken into account. The end column string is not defined by this function, but may or may not incorporate ECMA-48 CSI sequences that are intended to move the cursor up - and to the end of - the previous line. Previously, _eend() would always use the end column if was found to be non-empty, despite containing such sequences. Now, it will refrain from printing the end column where STDOUT is not a tty. Instead, it will fall back to the method of printing the success/failure indicator on the current line. Furthemore, if the fallback method is used under these exact circumstances, the number of available columns will be assumed as being 80 for the scope of the function call. After all, the width of the controlling terminal is wholly immaterial unless printing to it. This positively affects the following functions. - eend - ewend - veend - vewend Consequently, all eighteen of the aformentioned functions will act properly, in accordance with the state of both STDOUT and STDERR, at the time that they are called. As such, the truly repulsive hack that was to permanently disable colour if _either_ were found not to be a tty at the time of sourcing functions.sh has been jettisoned. Good riddance. Signed-off-by: Kerin Millar <kfm@plushkava.net> Bug: https://bugs.gentoo.org/631870 Signed-off-by: Sam James <sam@gentoo.org> functions.sh | 47 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 32 insertions(+), 15 deletions(-)
