stdout/stderr for text processes is ugly about assert_cmd

[tailhook]

No I'm not working on it.

You don't need \n unescaped linebreak works fine. (if you past your example into a Rust without editing you'll get two linebreaks, which is inconvenient)

[epage]

I'm in favor of

Format as binary, but line-by line. So weird characters are visible as escapes, but multi-line text output is readable

[smoelius]

Format as binary, but line-by line. So weird characters are visible as escapes, but multi-line text output is readable

Is the idea that a linebreak would be added after each \n?

E.g., something like this:

stderr=```<9910 bytes total>"    Blocking waiting for file lock on package cache\n    Checking libc v0.2.138\n    Checking cfg-if v1.0.0\n ....

Would instead look like this?

stderr=```<9910 bytes total>"    Blocking waiting for file lock on package cache\n
    Checking libc v0.2.138\n
    Checking cfg-if v1.0.0\n
....

@tailhook Are you working on this, by chance?

[smoelius]

I have a prototype working, but admittedly the boundaries between stdout, stderr, etc. become hard to find when the number of lines is large.

I can see at least six options.

1. Do nothing and live with the current "ugly" output.
2. Break lines unconditionally and live with the boundaries being hard to find.
3. Indent. However, like @tailhook aluded to above, this would cause a disparity between the actual text and the text displayed.
4. Add a method to Assert to enable this option. However, this could make for a confusing API. E.g., something like the following could cause a user to think with_linebreaks affects the predicate in stdout:

   Command::new(...)
       .assert()
       .with_linebreaks()
       .stdout(...);

5. Enable this functionality with a feature.
6. Choose a reasonable limit (similar to MIN_OVERFLOW, etc.) and show only a subset of the lines when the total number of lines would exceed that limit.

Thoughts?