CRLF/LF 문제

---

사건의 발단

• 맥에서 개발을 진행하다 도커 빌드 이슈를 만남
• 결국 맥에서 빌드하기를 포기하고 윈도우에서 도커 빌드를 실행하려던 찰나…

아래와 같은 이슈를 만나게 되는데…

[**entrypoint.sh](http://entrypoint.sh/) not found**

도커 파일이 잘못 말아진건가 싶어 들어가봤지만 entrypoint.sh은 그 자리에 잘 있는 것을 확인할 수 있었는데…(내용도 변함이 없어 보이지만..)

왜 이런 문제가 일어났지 - CRLF/LF 이슈가 존재

이러한 문제는 윈도우와 리눅스/맥의 줄바꿈 이슈로 일어날 수 있다

LF(\n)

- 아래로 이동
- 리눅스/맥에서는 위 방식을 채택하고 있음

CRLF(\r\n)

- 커서를 앞으로 당겼다가 아래로 이동
- 윈도우에서는 위 방식을 채택하고 있음

윈도우에서 도커 빌드를 해서 CRLF 로 파일 개행이 설정됐으나
리눅스(debian) 기반의 컨테이너에서 LF로 실행하려고 하여 일어난 이슈!

sh은 줄단위로 명령어를 해석하기 때문에 명령어 구문을 개행 문자로 구분함

→ 개행 문자는 중요한 역할을 함!
→ 이 때 개행문자를 알아볼 수 없다면, sh은 명령어를 해석하지 못함

진짜 맞는지 실험

• 유닉스 계열인 맥에서 파일 생성
• unix2dos 라이브러리를 이용해 unix format을 dos format으로 변경
• 개행 처리가 어떻게 돼있나를 확인
  • cat -e 옵션으로 확인(개행 문자를 시각적으로 표현)
  • 파일의 끝을 $로 표기함
  • 표기할 수 없는 문자를 caret (^)으로 표기
  • ^M은 CR (Carriage Return)을 의미함

1. 간단한 helloworld.sh 파일 생성 후 cat -e 명령어를 이용해서 출력
   
2. unix2dos 라이브러리를 이용해서 dos 형식으로 변경
   
3. 해당 파일을 다시 cat -e 로 출력 및 실행 → 실패!
   

그럼 어떻게 하지..?

• 네이버 코딩 컨벤션 등을 살펴보면 git 설정으로 lf 를 사용하도록 강제한다
  

• 혹은 ide에서 lf/crlf 로 전환 가능
  

(번외)그 밖에 왜 각 운영체제는 아래 방식을 채택했는가..

• 결론 : 실용주의자 유닉스파와 전통과 호환성을 중요시하는 윈도우의 자강두천 싸움