Console.WriteLine occasionally doesn't break the line

Question

I noticed in one of my application that calling Console.WriteLine() doesn't work every time.

Meaning, that the written string isn't terminated with a line break and the next call to Console.WriteLine() will be printed on the same line.

To test the behaviour, I have written the following reproducible app

@Wyck has contributed simpler code to replicate the issue:

for (var i = 0; i < 30; i++) 
Console.WriteLine(i.ToString().PadRight(100 + i, 'a'));

Here my original code with some bloat to it:

internal class Program
{
    static void Main(string[] args)
    {
        var rnd = new Random();

        for (var i = 0; i < 200; i++)
        {
            Thread.Sleep(rnd.Next(0, 10));
            var str = i.ToString().PadRight(rnd.Next(90, 130), 'a');

            switch (rnd.Next(0, 3))
            {
                case 0:
                    ConsoleEx.WriteLineInfo(str);
                    break;
                case 1:
                    ConsoleEx.WriteLineWarning(str);
                    break;
                case 2:
                    ConsoleEx.WriteLineError(str);
                    break;
            }
        }

        Console.ReadKey();
    }
}

internal static class ConsoleEx
{
    #region Static Public Methods

    public static void WriteLine(string str, ConsoleColor foregroundColor)
    {
        //var oldForegroundColor = Console.ForegroundColor;
        //Console.ForegroundColor = foregroundColor;
        Console.WriteLine(str);
        //Console.ForegroundColor = oldForegroundColor;
    }
    public static void WriteLineError(string str) => WriteLine(str, ConsoleColor.Red);
    public static void WriteLineInfo(string str) => WriteLine(str, ConsoleColor.Green);
    public static void WriteLineWarning(string str) => WriteLine(str, ConsoleColor.Yellow);

    #endregion
}

Things I noticed

• I could only replicate the issue by actually executing the generated *.exe, so never saw the issue while debugging.
• using redirect ConsoleApp.exe > output.txt doesn't seem to replicate the issue
• changing the ForegroundColor doesn't seem to contribute to the error

there for I believe it is maybe related to the Windows-Terminal Version I am using 1.16.10262.0

Here a screenshot of the issue:

Every number should be on a separate line, since all outputs are called with Console.WriteLine().

Is there something I can do in C#, or should I head over to https://github.com/microsoft/terminal/issues and report a bug?

Answer 1

You didn't change the width of the terminal window by any chance? - When narrowing it and expanding it again you can get a similar effect. Console.WriteLine(str); seems to work correctly - I tested it at home in the debugger window and Terminal Windows window.

Version: 1.16.10262.0

Answer 2

I don't have all the details here because it's a black box, but I think you've exposed a quirk (it may be legacy DOS behaviour) in how the terminal stores information in its screen buffer and how it reformats that data in the screen buffer to fit to a window of a different size.

The feature is called Wrap text output on resize.

Because of the way the terminal software buffers records the screen output by storing the printable characters and the coordinates to which they were displayed, it can't easily obviously tell the difference between a line that had a line ending at the last column and one that ran straight through because the line ending is not a printable character. This is because the cursor can be relocated to write to any location on the screen, yet you probably expect the screen buffer to be interpreted as an aggregate of the final printed output so that scrolling and copying do something reasonable.

The buffer basically works like a 2D array of printed characters. Non-printable characters (including the new-line) cannot be copied and pasted from the terminal buffer, for example, and have to be inferred from the layout. Yet line endings do seem to be preserved via a little bit of (perhaps not 100% correct the way you want it to be), magic in the implementation. When you resize the terminal it has to rearrange the printed characters from a 2D array of one width to a 2D array of a different width. But it clearly remembers something about the original layout at the time it was printed because the line endings are preserved mostly. But when the new-line is the last character of output, there's some ambiguity about what the buffer is supposed to look like with respect to word wrapping, so I think the implementation is just doing its best to make sense of things and do the right thing in most cases. (Again, think of how the ANSI output position controls work and the complexity of functionality it has to support.)

It has nothing to do with sleep :)

Again, there's probably some MS-DOS or ANSI control sequence legacy behaviour it's trying to preserve.