Date: Tue, 4 Apr 2017 23:05:51 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Andrey Chernov <ache@freebsd.org> Cc: Ed Maste <emaste@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r316477 - head/usr.bin/grep Message-ID: <20170404222532.X2274@besplex.bde.org> In-Reply-To: <4ceb1a18-3a72-c0e3-b2e2-f71d687cd153@freebsd.org> References: <201704032316.v33NGpbo037305@repo.freebsd.org> <4ceb1a18-3a72-c0e3-b2e2-f71d687cd153@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Apr 2017, Andrey Chernov wrote: > On 04.04.2017 2:16, Ed Maste wrote: >> if (color) >> - fprintf(stdout, "\33[m\33[K"); >> + fprintf(stdout, "\33[00m\33[K"); > > Please back that one out. We don't need to handle internally or print > remotely excessive 00. > At least according to > https://en.wikipedia.org/wiki/ANSI_escape_code > "With no parameters, CSI m is treated as CSI 0 m (reset / normal), which > is typical of most of the ANSI escape sequences." This might be to work around a bug in a terminal driver. I needed the 0 (but just one) to reset the attributes in my attribute tests, on at least 1 of the tested terminals (current sc, current vt, old sc, old xterm, old cygwin xterm). CSI m seems to be working for sc now, and the teken code looks OK. I first thought that this was a misplaced 0 for \033. 2 digits for octal looks strange. I would use hex in C anyway. In my user attribute tests, I have to use printf(1), and noticed that printf(1) is missing too many features in printf(3), or worse, is incompatible, especially for hex escape sequences and %c format. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170404222532.X2274>