Bug 1638447 - oc rsh introduces 0x0d control character
Summary: oc rsh introduces 0x0d control character
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: oc
Version: 3.10.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.11.z
Assignee: Juan Vallejo
QA Contact: Xingxing Xia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-11 14:55 UTC by Robert Bost
Modified: 2021-08-30 13:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-19 19:20:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3646891 0 None None None 2018-10-11 14:56:52 UTC

Description Robert Bost 2018-10-11 14:55:36 UTC
Description of problem:

Copying a file from a pod using `oc rsh` causes 0x0d (^M) control characters to be introduced. This can affect scripts that assumed only Linux-style newlines (0x0a, \n). 

This issue was found in OCP 3.2 but is still present in later versions. Here's an example of the introduction of the 0x0d character causing issues:

  https://github.com/openshift/ose/blob/enterprise-3.2/images/router/haproxy/reload-haproxy#L64

# oc rsh router-1-spmbp cat haproxy.config > myhaproxy.config
# grep -E '^\s*bind\s+:[[:digit:]]+\w' myhaproxy.config | cut -f2 -d: | paste -d, -s
,443

I would have expected the output from the command above to be "80,443" but the 0x0d characters cause cut/paste to behave unexpected.

# grep -E '^\s*bind\s+:[[:digit:]]+\w' myhaproxy.config | cut -f2 -d: | paste -d, -s | hexdump -C
00000000  38 30 0d 2c 34 34 33 0d  0a                       |80.,443..|
00000009


Version-Release number of selected component (if applicable):
atomic-openshift-3.10.45-1.git.0.3b98bf6.el7.x86_64 and earlier

How reproducible: alwayas


Steps to Reproduce:
1. oc rsh file from pod to local filesystem

Actual results:
Windows control character (0x0d) is introduced causing issues with Linux commands.

Expected results:
I would expect the oc rsh command to retain newlines as they exist on the pod.

Additional info:
- dos2unix command helps workaround issue.
- oc exec command does not introduce 0x0d characters.

Comment 1 Juan Vallejo 2018-10-18 20:20:51 UTC
Is this only happening on v3.10? Could you check if this issue can also be reproduced on a newer version, such as v3.11?

Comment 2 Robert Bost 2018-10-18 21:05:28 UTC
(In reply to Juan Vallejo from comment #1)
> Is this only happening on v3.10? Could you check if this issue can also be
> reproduced on a newer version, such as v3.11?

Yes, still occurs in 3.10:

[root@master-0 ~]# oc version
oc v3.10.45
kubernetes v1.10.0+b81c8f8
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://openshift.internal.rbost310.lab.rdu2.cee.redhat.com:443
openshift v3.10.45
kubernetes v1.10.0+b81c8f8
[root@master-0 ~]# oc rsh router-1-rn6cw cat haproxy.config > myhaproxy.config
[root@master-0 ~]# grep -E '^\s*bind\s+:[[:digit:]]+\w' myhaproxy.config | cut -f2 -d: | paste -d, -s
,443

Comment 3 Juan Vallejo 2018-10-18 21:35:14 UTC
Hi Robert,

Thanks for confirming, however I I'd also be interested to know if you're seeing this issue on a newer client, such as 3.11?

Thanks

Comment 4 Robert Bost 2018-10-18 21:42:38 UTC
(In reply to Juan Vallejo from comment #3)
> Hi Robert,
> 
> Thanks for confirming, however I I'd also be interested to know if you're
> seeing this issue on a newer client, such as 3.11?
> 
> Thanks

Yes, 3.11 is affected too

[root@master-0 ~]# oc version
oc v3.11.16
kubernetes v1.11.0+d4cacc0
features: Basic-Auth GSSAPI Kerberos SPNEGO

Server https://openshift.internal.nimeral.lab.rdu2.cee.redhat.com:443
openshift v3.11.16
kubernetes v1.11.0+d4cacc0
[root@master-0 ~]# oc rsh router-1-9fdvl cat haproxy.config > myhaproxy.config
[root@master-0 ~]# grep -E '^\s*bind\s+:[[:digit:]]+\w' myhaproxy.config | cut -f2 -d: | paste -d, -s
,443

Comment 5 Juan Vallejo 2018-10-19 19:20:07 UTC
Hi Robert,

The reason for the extra control character in the line-endings when using `oc rsh`, is because the `rsh` command requests a pseudo-terminal to be allocated by default. Running `rsh` with the flag `--no-tty` fixes this issue:

```
$ oc rsh router-1-... cat haproxy.config > myhaproxy.config
$ grep -E '^\s*bind\s+:[[:digit:]]+\w' myhaproxy.config | cut -f2 -d: | paste -d, -s
80,443
```

Comment 6 Juan Vallejo 2018-10-19 19:21:07 UTC
Correction to the example command in comment 5 (adding --no-tty flag):

```
$ oc rsh --no-tty router-1-... cat haproxy.config > myhaproxy.config
$ grep -E '^\s*bind\s+:[[:digit:]]+\w' myhaproxy.config | cut -f2 -d: | paste -d, -s
80,443
```

Comment 7 Robert Bost 2018-10-19 20:36:04 UTC
Is this something worth submitting a patch for? Something that keep newlines consistent based on client os?

Comment 8 Juan Vallejo 2018-10-22 18:14:53 UTC
> Is this something worth submitting a patch for? Something that keep newlines consistent based on client os?

This would most likely have to be a patch made against the docker term[1] package, which the rsh and exec commands depend on. You're welcome to make a patch there as you see fit, but considering that there is an option that allows `rsh` to behave exactly the same as `oc exec` (--no-tty), I do not think it is necessary.

1. https://github.com/moby/moby/tree/master/pkg/term


Note You need to log in before you can comment on or make changes to this bug.