Output overwritten by carriage return

[wiegandm]

Often -- but not always -- the output of autohooks is overwritten in my terminal by itself. For example, running autohooks check very briefly flashes single lines of text before they are overwritten by the following line. The final line is also overwritten, meaning no output is visible once the command is finished.

The behaviour described above is consistent among multiple terminal emulators and shells. However, sometimes the lines are displayed properly and then change back to being overwritten, in the same environment in subsequent runs of autohooks.

I strongly suspect this is related to erikrose/blessings#146. Capturing the output with script(1) does indeed show carriage return control characters (\r, ^M) being present at the end of every line:

Script started on 2019-12-20 08:49:42+01:00 [TERM="xterm-256color" TTY="/dev/pts/5" COLUMNS="212" LINES="58"]
^[7^[7^[[1Gautohooks pre-commit hook is active. ^[[206G [ ^[[32mok^[(B^[[m ]^M
^[8^[8^[7^[7^[[1Gautohooks pre-commit hook is outdated. Please run 'autohooks activate --force' to update your pre-commit hook. ^[[201G [ ^[[33mwarning^[(B^[[m ]^M
^[8^[8^[7^[7^[[1Gautohooks mode "pythonpath" in pre-commit hook python-gvm/.git/hooks/pre-commit differs from mode "pipenv" in python-gvm/pyproject.toml. ^[[201G [ ^[[33mwarning^[(B^[[m ]^M
^[8^[8^[7^[7^[[1GUsing autohooks mode "pythonpath". ^[[204G [ ^[[36minfo^[(B^[[m ]^M
^[8^[8^[7^[7^[[1GPlugin "autohooks.plugins.black" active and loadable. ^[[206G [ ^[[32mok^[(B^[[m ]^M
^[8^[8^[7^[7^[[1GPlugin "autohooks.plugins.pylint" active and loadable. ^[[206G [ ^[[32mok^[(B^[[m ]^M
^[8^[8
Script done on 2019-12-20 08:49:42+01:00 [COMMAND_EXIT_CODE="0"]

[bjoernricks]

My output of script -c "autohooks check"

Script started on 2019-12-20 09:08:05+01:00 [TERM="xterm-256color" TTY="/dev/pts/12" COLUMNS="271" LINES="64"]
^[7^[7^[[1Gautohooks pre-commit hook is active. ^[[265G [ ^[[32mok^[(B^[[m ]^M   
^[8^[8^[7^[7^[[1Gautohooks pre-commit hook is up-to-date. ^[[265G [ ^[[32mok^[(B^[[m ]^M
^[8^[8^[7^[7^[[1GUsing autohooks mode "pipenv". ^[[263G [ ^[[36minfo^[(B^[[m ]^M 
^[8^[8^[7^[7^[[1GPlugin "autohooks.plugins.black" active and loadable. ^[[265G [ ^[[32mok^[(B^[[m ]^M
^[8^[8^[7^[7^[[1GPlugin "autohooks.plugins.pylint" active and loadable. ^[[265G [ ^[[32mok^[(B^[[m ]^M
^[8^[8                                                                           
Script done on 2019-12-20 09:08:05+01:00 [COMMAND_EXIT_CODE="0"]

[bjoernricks]

Possible replacements for blessings which seems to be unmaintained erikrose/blessings#148

• https://github.com/timofurrer/colorful
  • most promising for me
  • no positioning api
• https://github.com/MasterOdin/crayons
  • used in pipenv
  • very simple and basic
  • no positioning api
• https://github.com/tartley/colorama
  • old stable project
  • supports windows
  • also used as base in other libraries

[jquast]

blessed is API compatible, supports windows, and is maintained, I'm sorry I missed this, but, I don't think your library is the problem... if you're going to use script(1) you're going to see ^M, that's introduced by your terminal in your terminal mode, though autohooks writes only \n, the terminal driver returns the carriage for you by translation.. programs like ls also have ^M output even though they don't explicitly do it. This isn't true if the terminal is in raw mode, though, where \r\n must be excplitily displayed.

I'm not sure what you were trying to fix, (maybe you're seeking term.move_x(0), combined with print("....", end="")?) or if your transition away from blessings went well, I just wanted to let you know about my fork. best wishes!

[bjoernricks]

Hi @jquast, we are facing an issue with setting the x location https://github.com/greenbone/autohooks/blob/v2.0.0/autohooks/terminal.py#L61 AND carriage returns. It seems that sometimes the indentation doesn't work with blessings, sometimes all output is writing in one line (the output is overridden with new output) and sometimes both. But we also haven't found a way to reproduce the behavior reliably. On my system the issue just did pop up and after a while mysteriously vanished without changing anything.

[jquast]

Hi @bjoernricks I think I know your problem(s), on move_x not working, this was a bug in blessings which we fixed in our fork since version 1.8,

enhancement: allow hpa and vpa (move_x, move_y) to work on tmux(1) or screen(1) by emulating support by proxy.

Does that sound like you? (Using tmux or screen).

[jquast]

I'm still not sure if I understand your carriage return issue, but, a very simple fix might be to use term.clear_eol code, it deletes everything to end of line,

    with self._term.location(x=self._indent):
        print(*messages, end=self._term.clear_eol + '\n')

edit: actually, I don't think this is your problem -- if move_x doesn't work, then, using the location manager would indeed keep printing over the same line over and over, so this "blessings bug" that we fixed in our fork a few years ago is most definitely your issue

[bjoernricks]

Screenshot of the current behavior. First call just doesn't print any output. Other two outputs are missing the indentation. This is within a tmux session but it is reproducible also without a tmux session.

[jquast]

two more suggestions

• I don't think the location manager should be used. We don't wish to return to any previous location. move_x would be fine on its own.
• there is no need to use move_x, anyway, did you know that it is non-destructive? so if anything is below it, it won't erase it, the bytes saved may not be worth it,

unless you're working with 9600bps terminal, just using ' ' * self._indent is perfectly portable, pipes to files and non-terminals, etc.

[bjoernricks]

Should be fixed with autohooks 2.1.0