Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better Line Endings Support #1340

Open
kdelorey opened this issue Nov 19, 2017 · 17 comments
Open

Better Line Endings Support #1340

kdelorey opened this issue Nov 19, 2017 · 17 comments

Comments

@kdelorey
Copy link

Expected behavior

Files copied to a Unix based image using ADD/COPY within a Dockerfile have their line endings [optionally?] converted to acceptable Unix line endings.

Actual behavior

Currently copied files will keep their Windows line endings ('\r\n'). This becomes problematic when you are trying to execute something like a bash script.

Information

Anything you want converted, you seem to have to do something similar to the following within your Dockerfile:

FROM ubuntu:16.04

RUN apt-get update -q \
        && apt-get upgrade -qy \
        && apt-get install -qy dos2unix

ADD dostuff.sh /dostuff.sh
RUN dos2unix /dostuff.sh

# ...

Docker = 17.11.0-ce-rc4-win39 (14244)
Windows = 10.0.16299

@docker-robott
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@kdelorey
Copy link
Author

/remove-lifecycle stale

@dsaborg-waya
Copy link

Yes please, this is very annoying.

@docker-robott
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30d of inactivity.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

@dsaborg-waya
Copy link

/lifecycle frozen

@dsaborg-waya
Copy link

/remove-lifecycle stale

@gilescope
Copy link

still an issue.

@macebalp
Copy link

macebalp commented Nov 29, 2018

+1. Different edit tools add windows line breaks to the files, so doing things like dos2unix always is not a good option.

@jufo
Copy link

jufo commented Feb 14, 2019

I've just run into this problem today.

@rhysjtevans
Copy link

rhysjtevans commented May 13, 2019

same here,
Automated pulling a git repo with bash scripts locally then running a docker build found that it had added \r\n instead of honoring the files line ending - very frustrating!

@guillaumerose
Copy link

/reopen

@docker-robott docker-robott reopened this May 23, 2019
@oznacargazi
Copy link

I am having this issue at the moment, dos2unix can help things but not always :(

@kszucs
Copy link

kszucs commented Aug 13, 2019

I'd like to see this issue resolved, using dos2unix introduces a lot of boilerplate for handling multiple dockerfiles.

@naleczynskia
Copy link

This is frustrating to me as well. It seems like line endings in context files are converted to CRLF even though I have repo cloned with autocrlf=input and source files contain line feeds. I have to run local docker build from under WSL to make it work.

@RedactedProfile
Copy link

RedactedProfile commented Oct 10, 2019

This is especially a problem if you're volume mounting a shell script. No amount of dos2unixing is going to fix it

@Pictor13
Copy link

Pictor13 commented Oct 27, 2020

For who's stuck with it: try adding a .gitattributes file, to influence how the files are being checked-out.

# Ensure shell script uses LF.
Dockerfile  eol=lf
*.sh        eol=lf
*.bat       eol=crlf

@vienleidl
Copy link

For who's stuck with it: try adding a .gitattributes file, to influence how the files are being checked-out.

How about bash files without .sh extension? Some files like /entrypoint or create-sftp-user without .sh extensions?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests