Context. In days of yore, people had 40x20, 80x24, etc. physical terminals. `tail` defaulted to 10 lines as an approximation of "half a screen". 1980s graphical window systems generalized this. Eventually shells grew SIGWINCH- managed $LINES. That can be used to recover a more terminal-aware default for `tail` which (esp. with a `nw` "no wrap" script wrapping a command in `printf '\033[?7l' & 'h'`) revives "half a screen" more precisely. So, I mirror with LC_LINES (to send this to older ssh) & have a Tail-Half shell script, `th`: #!/bin/sh budget=$((LC_LINES + 1 - 2*$#)) exec tail -n$((budget/2)) "$@" As written above, it adjusts for a "filename header" tail emits to fill a terminal screen *exactly* with no-need-to-scroll precision. Such screen precision off-by-8 when I ran `nw th hostAlog hostBlog` for logs from emerge (www-client/google-chrome was involved). This `tail` application is, of course, a special case of line framing with many line-oriented Unix tools. A simpler example is just `grep '!!'`. Sometimes such mis-framing/extended messages are intrinsic, but `emerge`'s ebegin/eend which send an `echo` ('\n') then "\e[A" pair (to go up a line) seems very avoidable. Compile/install log output is also more routinely captured by files/pipes where newline framing is more convenient. Looking at the code in sys-apps/portage `isolated-functions.sh`, the idea seems to relate to old RC_ variables probably from some progenitor known- terminal-codes virtual console boot log where someone decided aligned [ ok ] was more readable. (Sub-program output between ebegin & eend is already assumed to be more valuable than any text shape disruption.) The purpose of ENDCOL & its `RC_ENDCOL` activation variable seems to be to align `[`s over variable-length leading message text without trusting `LAST_E_LEN` (which I could see embedded color-escapes or UTF8 making inaccurate). Much code is already conditioned on `RC_ENDCOL`, but that variable is *hard set* at the end of the same file which from its filename having "isolated" probably intentionally sources as little as possible. Manual edit of `RC_ENDCOL="yes"` -> "no" (to rely on `LAST_E_LEN`) works for me (but maybe not for all ebuilds). SO! In light of all this: Solution1: Allow users to set `RC_ENDCOL` to "no" for more log- than terminal- oriented emerge output. This degrades isolation of `isolated-functions.sh`, BUT with no approved way to change this, all that code conditioning upon its value seems rather pointless. Maybe there is some way already? Did not seem so. This may also relate to NOCOLOR-like initiatives. Solution2: Instead of `echo` followed by "\eA[", do NEITHER - do ONLY $ENDCOL. Since _IONBF stderr is used here via >&2, _IOLBF should not be an issue, but it is likely that was the origin of the logic. { I.e. w/line-buffered output to a terminal the `echo` forced write(2) of the leading message - critical context if the whole logging process died for some reason. } Once >&2 got added, I think it could always have been this way, but that addition may well pre-date migration from whatever rc system this code was copied from. With this solution (& no supported way to set RC_*), all the logic conditioned on $RC_ENDCOL should still be reconsidered. Personally, I prefer Solution2, but Solution1 may be viewed as less of a perturbation or in need of less testing on all possible terminals. Related bugs I found, https://bugs.gentoo.org/117186 (about where these things are defined) & https://bugs.gentoo.org/631870 (about terminal portability, whose `tput` fix seems not to have made it to sys-app/portage's `isolated-functions.sh` yet, actually) are distinct. For now I am solving this myself with a /etc/patches/sys-apps/portage ="no" fix since that area of the file seems to have not changed since 2006. Even so, it seemed of potentially broader interest than only my own installs.
It doesn't help that there's three implementations of einfo et. al: 1) the bits in Portage 2) the bits in sys-apps/gentoo-functions 3) the bits in sys-apps/openrc (which the openrc maintainer has promised me will be split into an independent library - libeinfo)
