There's a known issue/behavior around docker run -t
stdoutstderrstreams both go tostdoutLF(\n) replaced ->CRLF(\r\n)
There're explanation in the net that CRLF replacements is the matter of an allocated tty it self.
With this in mind
There's an app that under the hood wraps calls to docker run -t bypassing stdio completely as is. It runs it own logs under stderr and LF driven
As a result (combination of docker stdout:CRLF and logs stderr:LF) the output in the terminal differs depending on another option docker run -I
For docker run -t it is
[err] regular app logs LF
[err] regular app logs LF
[out] docker related outputs CRLF
[out] docker related outputs CRLF
[err] regular app logs LF
[err] regular app logs LF
But for docker run -it the terminal output starts being displayed corrupted just after the first CRLF occurrence (yet in byte representation content looks very similar for run -t outputs)
[err] regular app logs LF
[err] regular app logs LF
[out] docker related outputs CRLF
[out] docker related outputs CRLF
[err] regular app logs LF
[err] regular app logs LF
[err] regular app logs LF
It looks like terminal automatically switches to CRLF mode ofter the first appearance and for the LF simply changes the line without turn the carriage back.
So what is not clear
- Actually for what reason the
docker(it looks like) gluesstdout+stderr - Once
CRLFreplacement is the matter of terminal it self why doesn't it do this in consistent way both forstdoutandstderras well - Why for (seems to be) similar output content on a same terminal the view of logs differs for
-tand-itruns (the commands actually don't rely instdinat all)
And for the following it maybe should to be asked in a standalone question but mainly this is more about are these related to the root problem cause at all
- At least would it be proper to turn
CRLFbehavior for the terminal (it is macOS) - in
itermI didn't findCRLFrelated option neither onTextnorTerminalsection - How
sttyanditermsettings relate each other
Thanks