Currently Python code using eend (like 'checking * checksums') is outputting the '[ ok ]' part with right alignment to the column before the last one. The bash code (although looking similar) outputs it aligned to the last column. I think that should be unified. To be honest, I would prefer adjusting the bash implementation to match Python one as reaching EOL there makes curses (and thus portage-jobsmon) wrap the line just before \n.
Both implementations appear pretty similar to me, so it's not immediately obvious what needs to be changed here: pym/portage/output.py: self._write(out, "%*s%s\n" % ((self.term_columns - self.__last_e_len - 6), "", status_brackets)) bin/isolated-functions.sh: if [[ ${RC_ENDCOL} == "yes" ]] ; then echo -e "${ENDCOL} ${msg}" else [[ ${LAST_E_CMD} == ebegin ]] || LAST_E_LEN=0 printf "%$(( COLS - LAST_E_LEN - 6 ))s%b\n" '' "${msg}" fi
This seems to be more of a RC_ENDCOL issue. I'm attaching a patch which changes ENDCOL to behave like Python eend. Moreover, after disabling RC_ENDCOL the _eend function seems to work improper when called with other efunction than ebegin (like epatch does) - it outputs the '[ ok ]' in next line then. And bash gets other column count than portage (AFAICS, in _eend() COLS is 118 while in Python counterpart it's 126). That difference is probably related to decreasing COLS in set_colors() which non-RC_ENDCOL implementation doesn't seem to be aware of. And last of all, when doing parallel merges bash counterpart is unable to get terminal size while Python code (having the direct terminal access) gets it correctly. Thus, the 'checking' output is aligned for full-width terminal and further eends are aligned for 80-char wide terminals. Thus, whenever associated message is longer than 80 chars, '[ ok ]' is inserted in the middle of it. Python could pass the terminal size to bash code.
Created attachment 223383 [details, diff] Make ENDCOL behave like Python _eend()
I forgot to mention I'm wondering about that BSD decreasing code - if that's related to having to not reach EOL on these systems, then I think that can be dropped now, as with the patch we aren't reaching EOL anymore.
Created attachment 223399 [details, diff] bsd cons25 columns adjustment from svn r6467 (In reply to comment #4) > I forgot to mention I'm wondering about that BSD decreasing code - if that's > related to having to not reach EOL on these systems, then I think that can be > dropped now, as with the patch we aren't reaching EOL anymore. Well, the BSD cons25 code is in both the bash and python implementations, so maybe that's a separate issue.
That's not exactly what I meant. I've pinged uberlord to confirm my assumption. What I think, is that Python/non-ENDCOL implementation (mistakenly?) ends writing one column before EOL while ENDCOL reaches EOL. If I understand everything right, the EOL-reaching behaviour is correct although it's not tolerated on BSD (and that's when the patch comes into action). But IMO it would be better to always avoid reaching EOL instead of working that around for BSD. And that would take: 1) reverting changes from r6467, 2) adjusting ENDCOL to not reach EOL (my patch), 3) fixing non-ENDCOL bash output to take into account that COLS were mangled or avoid mangling COLS there (that's the separate issue). I'll let you know when I get uberlord's reply.
Created attachment 224351 [details, diff] The patch addressing all of the related issues Although I haven't got reply from uberlord, I've investigated the code a little and found few inconsistences and issues, especially in the bash part. I'm attaching a fresh patch, fixing all of them. There's a detailed explanation of the changes inside the patch. I have tested it in various scenarios, including the RC_ENDCOL & RC_DOT_PATTERN ones, and had no problems with it. I'm not sure about the reason for the last changes in the Python part though, and I'll have to investigate that further.
Created attachment 224455 [details, diff] Updated and fixed patch I've investigated the issue more and choose better solution for Python eend position. I've also replaced the one part which was diffed against modified sources.
Created attachment 224457 [details, diff] COLS-- incorporated into eend()
(In reply to comment #9) > Created an attachment (id=224457) [details] > COLS-- incorporated into eend() Thanks, that's in svn r15839.
This is in 2.2_rc68, but I'll leave this bug open until it's in an unmasked version.
This is fixed in 2.1.9.
