colima
colima copied to clipboard
LF characters in container stdout are converted to CRLF
Description
Newlines in container stdout are converted to CRLF.
Example:
tuure ~ $ docker run --rm -it ubuntu:24.04 sh -c 'echo "a\nb"' | xxd
00000000: 610d 0a62 0d0a a..b..
If I instead base64-encode the stdout, the conversion doesn't happen
tuure ~ $ docker run --rm -it ubuntu:24.04 sh -c 'echo "a\nb" | base64' | base64 -d | xxd
00000000: 610a 620a a.b.
The instance is a VZ instance (for Rosetta suppport), and was created like:
colima start --vz-rosetta --vm-type vz --cpu 10 -d 30 -m 7 --activate
Version
tuure ~ $ colima version && limactl --version && qemu-img --version colima version 0.7.5 git commit: 1588c066b9ab9dae8205ef265929c7eb43dca473
runtime: docker arch: aarch64 client: v27.3.0 server: v27.1.1 limactl version 0.23.2 qemu-img version 9.1.0 Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers
Operating System
- [ ] macOS Intel <= 13 (Ventura)
- [ ] macOS Intel >= 14 (Sonoma)
- [ ] Apple Silicon <= 13 (Ventura)
- [X] Apple Silicon >= 14 (Sonoma)
- [ ] Linux
Output of colima status
tuure ~ $ colima status
INFO[0000] colima is running using macOS Virtualization.Framework
INFO[0000] arch: aarch64
INFO[0000] runtime: docker
INFO[0000] mountType: virtiofs
INFO[0000] socket: unix:///Users/tuure/.colima/default/docker.sock
Reproduction Steps
docker run --rm -it ubuntu:24.04 sh -c 'echo "a\nb"' | xxd
Expected behaviour
Expected newlines not to get converted to CRLFs.
Additional context
The CRLFs can be observed coming from the docker daemon, i.e. they are not an artifact of the client:
Extract from socat dump showing the stdout request and initial response
> 2024/09/22 00:42:31.000202662 length=291 from=0 to=290
50 4f 53 54 20 2f 76 31 2e 34 36 2f 63 6f 6e 74 POST /v1.46/cont
61 69 6e 65 72 73 2f 66 33 39 64 36 66 32 31 33 ainers/f39d6f213
66 61 37 66 36 38 65 62 65 66 35 63 65 61 66 34 fa7f68ebef5ceaf4
32 63 65 61 33 30 65 30 32 38 30 39 33 62 32 39 2cea30e028093b29
30 66 33 36 38 61 61 63 32 31 63 32 32 32 65 38 0f368aac21c222e8
61 36 35 35 63 35 62 2f 61 74 74 61 63 68 3f 73 a655c5b/attach?s
74 64 65 72 72 3d 31 26 73 74 64 69 6e 3d 31 26 tderr=1&stdin=1&
73 74 64 6f 75 74 3d 31 26 73 74 72 65 61 6d 3d stdout=1&stream=
31 20 48 54 54 50 2f 31 2e 31 0d 0a 1 HTTP/1.1..
48 6f 73 74 3a 20 61 70 69 2e 6d 6f 62 79 2e 6c Host: api.moby.l
6f 63 61 6c 68 6f 73 74 0d 0a ocalhost..
55 73 65 72 2d 41 67 65 6e 74 3a 20 44 6f 63 6b User-Agent: Dock
65 72 2d 43 6c 69 65 6e 74 2f 32 37 2e 33 2e 30 er-Client/27.3.0
20 28 64 61 72 77 69 6e 29 0d 0a (darwin)..
43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 Content-Length:
30 0d 0a 0..
43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 55 70 67 72 Connection: Upgr
61 64 65 0d 0a ade..
43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 Content-Type: te
78 74 2f 70 6c 61 69 6e 0d 0a xt/plain..
55 70 67 72 61 64 65 3a 20 74 63 70 0d 0a Upgrade: tcp..
0d 0a ..
--
< 2024/09/22 00:42:31.000203964 length=109 from=0 to=108
48 54 54 50 2f 31 2e 31 20 31 30 31 20 55 50 47 HTTP/1.1 101 UPG
52 41 44 45 44 0d 0a RADED..
43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 Content-Type: ap
70 6c 69 63 61 74 69 6f 6e 2f 76 6e 64 2e 64 6f plication/vnd.do
63 6b 65 72 2e 72 61 77 2d 73 74 72 65 61 6d 0d cker.raw-stream.
0a .
43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 55 70 67 72 Connection: Upgr
61 64 65 0d 0a ade..
55 70 67 72 61 64 65 3a 20 74 63 70 0d 0a Upgrade: tcp..
0d 0a ..
And later the contents:
--
< 2024/09/22 00:42:31.000365423 length=6 from=109 to=114
61 0d 0a a..
62 0d 0a b..
--
A random thought: HTTP headers are \r\n-terminated. Could it be that whatever is relaying the stdout stream over HTTP thinks it's writing HTTP headers and converting the newlines?