Stdout from container into host pipe weirdness

Docker Desktop
1

Running the latest docker desktop 2.1.0.5 (and same on the few months old docker I had before upgrading while trying to fix this issue) on Mojave 10.14.6 I get some weirdness when I pipe the output from a container into something on the host. It looks like the carriage return action of a newline is ignored so the next outputted line will start one row just below the last character instead of at column 1 on the next row.

This happens in a number of different scenarios. I’ve tried with Ubunto, Debian and Alpine as the container OS and with dd’ing /dev/random, or just a plain seq number sequence or the output from a verilog testbench. It also happens regardless of if I’m running iterm2 or the native terminal on the mac. Also it doesn’t matter it I pipe into tee or hexdump. The displayed data still ends up with faulty carriage returns like in the image here where I first do the “seq” command in a container (ends up garbled) and then locally in the mac where it’s ok.

Screen Shot 2020-01-05 at 12.10.14 AM
Screen Shot 2020-01-05 at 12.10.14 AM2138×720 224 KB

Funnily enough it corrects itself after a shedload (like half a million in this case) of lines.

Non-inlined image here since I’m a new user at the forum:

[Album] imgur.com

But if I redirect the output into a file the file ends up perfectly fine - so that is a workaround for me. I can postprocess the results after the container has ended, but that means I can’t see whats happening during the actual run (which lasts up to 30-60 seconds).

I can’t figure out what to try next…

2

If you just want to work with the piped output, use it like this:
docker run --rm --log-driver=none -a stdout -a stderr alpine seq 1 20 | hexdump -C
(Hint: adding -t for an interactive terminal will break the output.)

If you want to pipe something into the container and work with the piped output:
seq 1 20 | docker run -i --rm --log-driver=none -a stdin -a stdout -a stderr alpine hexdump -C | cat -
(The second will not even with the -t option, though it will require -i to process the piped in data)

Both commands result in the same output on my Ubuntu 18.04 / Docker 19.03.5 machine.

1 Like
3

Thank you! Now it works perfectly.

I’ve got an alias named DR that starts an interactive auto-removed container with diskmapping for general usage, and I used the same in my script. It didn’t occur to me that the the terminal part was the culprit since the container output obviously was sent to stdout regardless. You learn something new every day, hopefully I’ll remember this the next time :wink:

1 Like