얼마전 사이드 프로젝트 환경 세팅하기 위해서 docker compose를 사용하면서 위와 같은 이슈가 발생했습니다. 개인적으로 사용하는 노트북이 맥 환경이었고 회사에서 잠깐 테스트로 작성하던 도중 발생한 이슈입니다.
문제
docker compose 실행 이후 아래와 같은 이슈 발생
/usr/bin/env: ‘sh\r’: no such file or directory 에러원인
원인은 소스코드의 개행문자(줄바꿈) 처리가 OS에 따라 상이하다는 것입니다. 윈도우의 경우는 \r\n이고 유닉스 계열은 \n이 됩니다. 그래서 윈도우 환경의 소스코드를 docker compose로 생성된 리눅스 환경에 배포할 때, 개행문자를 잘못 인식하게 됩니다. 그래서 에러메세지 중 \r이 나오게 되는데 이것은 윈도우에서 생성된 소스코드 중 마지막 문자의 줄바꿈 \r\n에서 \n만 인식한채 \r은 인식하지 못해서 생긴 오류라고 생각됩니다.
첫번째 해결법
해결법을 찾던 도중, IDE의 도움을 받아 윈도우 환경의 코드를 유닉스 계열코드로 바꿀 수 있다는 것을 알게 되었습니다. 개인적으로는 intellij를 사용하고 있으며 다음과 같은 설정을 해주면 된다고 나와있습니다.
Settings -> Editor -> Code Style -> Line separator : Unix and macOS (\n)
보시다 시피 line sparator를 유닉스 개열로 바꾼다 라고 되어있습니다. 그리고 다시 시도해 보았지만 결과는 여전히 같았습니다. 나중에 안 사실이지만 자세히 보면 Applied to new files라고 아래 작은 글씨로 적혀있습니다. 아마 git으로 받아온 기존 파일에는 적용이 되지 않고 설정을 변경한 시점부터 새로 작성되는 파일에만 해당하는 것으로 보입니다. 처음부터 코드를 작성한다면 위와 같은 설정을 하는 것이 좋을 것 같습니다.
두번째 해결법
그렇다면 git에서 소스코드를 받아올 때, 윈도우에서도 리눅스의 시스템을 사용할 수 있도록 설정을 해주면 될 것이라 생각되었습니다. git 자체에서 해결해주는 방법이 있었는데 키워드는 WSL (Windows Subsystem for Linux)입니다. 말 그대로 윈도우 기반에서 리눅스 환경과 호환이 잘 되도록 세팅해주는 방식입니다. Setup Git in WSL에서 제시한 해결책은 다음과 같습니다.
git config --global core.autocrlf falsecore.autocrlf 옵션은 git 공식 홈페이지에 자세히 설명 되어있습니다. 간단히 설명하자면 윈도우는 조용히(?) LF 스타일의 라인 엔딩을 CRLF 방식으로 바꿉니다. 공식 홈페이지에서도 직접 annoying이라는 단어를 사용하면서 크로스 플랫폼이 얼마나 거슬리는(?)지 잘 설명하고 있었는데요 마치 저의 마음과 같았습니다. 그래서 자동으로(auto) CRLF(crlf)를 바꾸는 것을 사용하지 않으면(false) LF 스타일로 사용할 수 있음을 알 수 있었습니다. 해당 설정을 해주시고 프로젝트를 clone하면 정상적으로 동작함을 알 수 있습니다. 자세한 내용은 git 공식 홈페이지를 참고하시기 바라겠습니다.
