흠..... ftp 로 전송했는데,
사이트는 안열리고, 아파치 로그에는 계속 오류만 뿜어서, 검색해봤더니... ㅠㅠ
파일질라 전송타입을 auto ---> Binary 로 변경하니 됐다.
The default transfer type is set as Auto which is the reason in my case.
The solution is that set the default transfer type as Binary.
검색해보니...
업로드 한 shell을 실행하면 다음과 같은 에러 메시지가 떨어진다.
bash2: ./test.sh: /bin/sh^M: bad interpreter: 그런 파일이나 디렉토리가 없음
에러 메시지를 잘 보면 ^M <- 이 문자열이 보일 것이다.
이것은 실제 /bin 디렉토리의 sh^M 이라는 shell 스크립트를 찾으려고 했기 때문에 발생된 오류이다.
그럼 왜 저런 문자열이 붙어 있는 것일까?
이는 FTP 업로드에서 찾아볼 수 있다.
FTP 전송 유형에는 ascii, binary 이렇게 두 가지를 지원하는데 ascii로의 파일 전송 시에는 윈도우에서 개행으로 사용하는 \r\n 이 리눅스로 업로드 되면서 \n 으로 변경되게 된다.
하지만 binary 전송 유형은 아무런 변환 과정 없이 그대로 \r\n 이 포함되어 업로드 된다.
결국 리눅스에서의 개행 문자 \n 을 제외한 \r 은 ^M 와 같은 문자열로 표시가 되어 문제를 일으킨다.
그러니 윈도우에서 shell 작업 후 리눅스에 FTP 업로드 할 때에는 꼭 ascii 전송 유형으로 변경 후 업로드 하자.
FTP 전송시 ASCII 와 Binary 전송 모드가 존재하는 배경 및 차이 설명
간략하게 요약한다면. ...
기본적으로, END-OF-LINE ( EOL ) 과 END-OF-FILE (EOF) 를 표시하는
코드값이 기종마다 다르다.
아래를 참조하라..
--------------------------------------------------------------------------
System EOL EOF
--------------------------------------------------------------------------
IBM, DOS, Windows, VAX-VMS 13[CR]+10[LF] 26[^Z]
Linux, Unix 10[LF] 04[^D]
Macintosh OS 1-9 13[CR] 04[^D]
Macintosh OS X Flexible:either [LF] or [CR] 04[^D]
-ASCII 모드 :
8bit 중 하위 7bit 만 사용 (1bit 는 다른 목적으로 예약)
RAM이 비싸던 시절에 대두, 그 때는 적절했겠쥐..
위의 목록에서 정리한 변환과정이 포함됨
기종간 EOF, EOL 문제로, ASCII 모드를 없애지 못함 (공존의 이유..)
-Binary 모드 :
8bit 모두 사용 (1bit 값마저 유용한 데이타로 사용하는 프로그램들의 등장으로)
MS워드, 이미지, 비디오 등등등
8bit 모두가 유용한 정보인데 7bit 만 사용하면 결국 파일은 1/8의 손실이 감수되므로. ㅠㅠ
위의 변환과정이 전혀 포함되지 않음
따라서,
Windows 에서 생성된 TXT파일을 Binary모드로 유닉스장비로 전송한다면
변환없이 그대로 저장되므로
vi로 열었을 경우 ^M 이 나타나게 되겠죠.. ^^;
그래서, 압축해서 ftp 전송하고, 서버에서 푸는 방식이 안전한 듯
댓글