last log to stdout during step is lost due to ANSI color escaping about behave HOT 6 CLOSED

I assume that you are using the pretty formatter ?!?
In this case, the —no-color option causes a different behavior in the pretty formatter. In colored mode, it writes the steps twice:

• Once before it is executed (in gray)
• And another time after the step has finished and the result is known
• It overwrites how much lines this step needs

If you do not capture the output, behave is not aware of any printed output.
Therefore, such output lines are overwritten.

You seem to need a feature, like:

• show-always-captured-output (after the step is executed or after scenario is executed)
• You should be able to provide the basic functionality for this by using an after_scenario() hook that uses:

def after_scenario(ctx, scenario):
   # PRECONDITION: Captured output is stored only if junit reporter is enabled (for passing scenarios).
   report = scenario.captured.make_report()
   if report:
      print(report)

• You could do the same with an after_step() hook, that output the ctx.scenario.captured.make_report(). To simplify things, you should probably reset the captured output after each step.

from behave.

Sorry, I disagree.
That is as if you blame your car manufacturer that you are in a traffic jam.

If you use -no-capture, etc. the output/log-output is outside of behave.
Therefore, behave can not do anything about it. That is a deficit of the pretty formatter and maybe unexpected for you and others. But you are free to:

• choose another formatter
• use the pretty formatter without color
• capture the output/log-output and
• perform something like show-always-captured-output with captured-output/log-output (where currently only rudimentary support exists)
• use logging to a file without capturing it (to inspect it later-on)

OTHERWISE:
If you have a better, robust solution how the pretty formatter should behave in colored mode, provide a pull-request.

from behave.

MAYBE RELATED FIX:

• #1120 — INTEGRATED INTO: behave v1.2.7.dev4

Therefore, try the tip of the repository or behave v1.2.7.dev4 or newer (installed from the Git repository)

NOTE:
By shortly looking over the implementation, —no-color option should not have any effect on logging output.

from behave.

This bug isn’t specific to logging. It seems that if a step writes to stdout (and it isn’t captured), then the last line of output is lost. A logger configured as above is one way to hit this. A plain old print statement is another.

My assumption is it gets overwritten when behave tries to change the step text to green.

from behave.

@jenisys This is clearly a bug in behave caused by two of its features (--color and --no-capture) interacting poorly. It's not a feature request, and I'm not "mistaken".

To fix this bug, the "pretty print" logic or whatever needs to be fixed to detect this situation and respond appropriately.

from behave.

No, it's as if turning on the windshield wiper caused the radio to stop working, and my car manufacturer refused to admit there was a problem.

The bug comes from here, where it uses a special ANSI code to "rewind" the terminal to the previous line.

I don't use ANSI escape sequences, but it seems you should use the DSR escape sequence to get the current offset before writing the step text (orig_offset). Then after the step has executed, save the current offset again (new_offset), use the CUP escape sequence to restore orig_offset, overwrite the step text in green/red, and then restore new_offset. Of course, that will not work properly if stdin is being used for another purpose.

Barring that, you should (1) change the default behavior to disable colors if any output capture is disabled, and (2) amend the documentation for --color to mention this flaw.

from behave.