\n 과 \n\r
글쓴이: applectron / 작성시간: 화, 2004/01/06 - 3:37오전
유닉스에서는 텍스트파일에서 \n 가 줄 구분자이고,
윈도우즈에서는 텍스트파일에서 \r\n 이 줄 구분자입니다.
여기까지는 대부분 다 아는 내용인데요.
근데 이 ㅤㄸㅒㅤ 두 가지의 궁금증이 생깁니다.
첫째 궁금증은,
왜 OS마다 줄 구분자를 다르게 정해놓은 건가 하는 것입니다.
둘째 궁금증은, 유닉스랑 윈도우즈랑 줄 구분자가 다르면 서로 텍스트파일 교환시에
불편한데, 유닉스나 윈도우즈나 둘다 \n 과 \r\n 을 모두
줄구분자로 인식하도록 새로 짜면 서로 편하지 않을 까요?
윈도우즈와 유닉스 두 OS 모두에서 텍스트파일의 \n의 이전에 붙는 \r를
무시하고 무조건 줄 구분자로 인식하기로 약속을 정하면, 일단 약속이
이렇게 정해지면 두 OS의 텍스트에디터들의 다음버전은 이런 약속을
실천하는 버전으로 나올 것이고 그러면 유닉스랑 윈도우즈랑 서로
텍스트파일이 간단히 호환되게 되는데, 이렇게 안하는 특별한 이유가 있을까요?
Forums:
ㄸ ㅒ오타겠죠? 두벌식에선 때 쓰기가 쉽지 않죠?OS에 따라
ㄸ ㅒ
오타겠죠? 두벌식에선 때 쓰기가 쉽지 않죠?
OS에 따라 줄 구분자를 다르게 쓰는것에 대해서는 두가지 방법이 있겠죠.
하나는 OS에 관계없이 똑 같은 걸 쓰도록 규정을 만드는 것. 그럼 어느쪽을 따라야 할 것이냐가 문제가 되겠죠. 개인적인 생각으로는 1byte라도 절약하는 유닉스쪽의 방식이 좋다고 생각합니다만, 엠에스윈도쪽에서 그것에 따라야 한다는 법이 있는 것도 아니고...
또 하나는 프로그램차원에서 두가지 구분자를 다 줄 구분자로 인식하게 하는 방법.
기존의 프로그램이 다시 짜 져야 하므로 꽤 많은 시간과 노력이 들겠죠.
팁.
유닉스 방식으로 저장된 텍스트 파일을 엠에스윈도의 노트패드로 보면 제대로 안 나옵니다. 이런 파일은 노트패드 대신 워드패드에서 읽어서 저장하면 엠에스에서 쓰는 방식으로 저장됩니다.
세벌 https://sebuls.blogspot.kr/
unix 측에서 보면은 M$가 후발 업체인데...unix 측면에서의
unix 측에서 보면은 M$가 후발 업체인데...
unix 측면에서의 M$로의 전환은 어이가 없는거구...
비용도 정말 만만치가 안을듯 하네요...
그리고... 모든게 통합이 되면은 좋겠지만...
굳이 크게 문제가 되지 않는 부분이라면...
그것의 특징으로 다른점으로 봐주면 되는 문제 같네요...
정말 변경을 한다면...
newline 부분 보단... 프로그래머 입장에선...
lidian 문제가 통일 되면 머리가 좀 덜 아프겠죠...^^
<어떠한 역경에도 굴하지 않는 '하양 지훈'>
#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);
더 좋지 않나요?
약간 변태(?)스럽게 보일 수도 있겠지만...
원래 파일이 어디에서 만들어졌는지를 알 수 있어서 전 좋던데요... 8)
변환을 해주던지 아니면 지원되는 편집기에서 열면 문제 없을 것같고요.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
아래글은 8bit 때부터 느낀 느낌입니다.아마 DOS가 \r\n
아래글은 8bit 때부터 느낀 느낌입니다.
아마 DOS가 \r\n 을 개행(New line)으로 사용한이유는
초기 값싼 화면 처리를 위해서일 것입니다.
개행이라는 것은 정확히 Cariage Return + Line Feed로 되어 두번의 액션으로 되는 것이 맞습니다.
한번은 그 행의 맨 처음으로 이동하는 것(\r)과 한번은 다음줄로 이동하는 것(\n)이죠. 유닉스에서는 초기부터 터미널이라는 것이 존재했고, 그 터미널 제어 코드로서의 \n (Line feed ) 을 사용했습니다.
제어 모드에 따라서 단지 Line feed(LF)만 할 것이냐 Cariage Return(CR)까지 할 것이냐를 결정할 수 있는 것입니다.
흔히 Vi 를 터미널에 띄우고 있는데 시스템 메시지로 뭔가가 2줄 이상 쓰여지면, LF만 동작하는 것은 터미널 모드가 vi로 진입하면서 바뀌기 때문입니다.
그런데 DOS 혹은 그 이전 CP/M부터(DOS와 CP/M은 다른 회사에서 만들었죠?) 그런 비싼 터미널을 채용하지 않았고, 따라서 LF 의미가 어떤 모드에 따라 달리 작동하는 방식으로 구현되지 않았을 것입니다.
그런 유산을 그대로 물려 받은 것이죠.
apple의 CR 의 경우 ( 이것도 제 생각입니다만, ) 키보드의 입력값을 그대로 살린것으로 생각합니다. 키보드의 (Return Key) 명령은 한 바이트로만 해석되었고 정확히 CR값을 입력하는 것입니다. 따라서 이도저도 귀찮았는지 CR을 개행으로까지 확대적용한 것 같습니다.
(전 Apple 스펙을 보지 않아서 CR이 단지 Cariage return만하도록 행동을 바꿀 수 있는지는 모르겠습니다.)
지금와서 개행 방법을 바꾼다는 것은 아마... 어려울 것으로 보입니다.
---
http://coolengineer.com
vim에서 dos형식과 unix형식을 바꾸는 팁은 다음과 같습니다.
vim에서 dos형식과 unix형식을 바꾸는 팁은 다음과 같습니다.
:set filetype=[dos|unix]
빨랑 novice를 벗어나고 싶다.
VENI, VIDI, VICI - Caesar, Gaius Julius -
좀 더 짧게 :set
좀 더 짧게
:set ff=unix|dos
와 같이 할 수도 있습니다. :-)
전 그냥
편집할 때 마다 형식 가리지 않고 마구 편집합니다.. (주로 Linux/Mac을 써서 일지도 모르지만)
그러다가, 리눅스에서 윈도에서 작성된 텍스트라서 신경이 거슬리면
조용히
dos2unix 파일명
해버리곤 하지요.
================
Lunatine
================
================
Lunatine
================
오오옷^^;
감동먹고 한줄이라도 감탄사를 적지 않으면 안된다는 강한 압박감이
뇌리를 스치는 듯한 기분이 전신을 휘감는 듯한 느낌에 휘둘려버렸습니다.^^;
역시 moderator의 내공만빵이 전해져오는 명답입니다.
사실, pynoos님의 답이 100% 정답인지 아닌지도 판단할수 없는
수준인지라, "명답입니다"가 아니라 "명답인것 같습니다"라고 정정하겠습니다.
역시 어떤 답이 올라올지 "감시"하길 잘했습니다.^^;
그러니까, terminal이랄지 하는 것들을 첨부터 제대로 접해보지 않은지라,
왜 그런지라는 부분에 있어서 원리적인 접근이 어려운 점이 있습니다.
아니, 실은 이것은 공부를 게을리 한 탓일 것입니다.
그냥 막연하게, escaping의 의미랄지, editor의 방식이랄지 하는 것들에
대해 어렴풋이 알고 있는 내용들도, 근본 이유에 입각한 명쾌한
정리가 없으면 허상인거죠.
terminal제어코드로서의 cr과 lf를 이처럼 멋지게 설명해주신 pynoos님께
너무 감사드립니다.^^;
(좀 오버라구요? 그런지도^^; 하지만, 원래는 에디터의 방식이랄지 그런게
아니라, 터미널(sw가 아닌 hw! )의 제어코드였다는 점은
저같은 초심자는 잘 알수 없거든요.
아, 걍 훑어봤던 serial programming for c programmer 정독해야겠단
생각이 마구 듭니다^^).
--------------------------------------------------------------------------------
＼(´∇`)ノ ＼(´∇`)ノ ＼(´∇`)ノ ＼(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)
참고로... /n 이니 /r 등은 터미널을 위한 제어코드라기 보다는 문자
참고로... /n 이니 /r 등은 터미널을 위한 제어코드라기 보다는 문자셋 자체가 가지고 있는 제어 코드 입니다.
사실 line feed(한라인만큼 이동), cariage return(라인의 맨처음으로 돌아가기) 등의 개념은 옛시절 쓰이던 라인프린터 같은 것을 위해 설계된 개념이라고 보입니다. ;)
My Passion for the Vision!
[quote="Viz"]참고로... /n 이니 /r 등은 터미널을 위한
맞습니다. :D
\r \n 은 C/C++ 및 그 전통을 따르는 언어에서만 쓰이는 것입니다.
ASCII CODE 13 (CR) 10 (LF) 로 해야합니다.
---
http://coolengineer.com
Python은 2.3부터 Universal Newline을 지원해서 파일
Python은 2.3부터 Universal Newline을 지원해서 파일을 읽을 때
"rU" 모드로 열어주면, 모든 OS에서 다른 OS들의 뉴라인 문자를
자동으로 인식해서 처리해 줍니다. :)
You need Python
헛..
좋은팁 감사합니다. 역시 퍼키님~
================
Lunatine
================
================
Lunatine
================
네, 그렇군요^^;
뭐랄까, 혼동을 하게 되는 거랄까요?
어디까지가 HW고 어디까지가 SW인지,
또 어디까지가 op code고 어디까지가 operand인지...
혼동될 때가 있습니다.^^;
과거 터미널이나 line printer는 자신에게 전송되는 데이터중에
control byte를 만나면 그만큼 옆으로 이동하거나, 줄 처음으로 가거나
다음줄로 가기 위해 motor를 돌리던지 했을거라는 생각이^^;
그리고, 그런 일련의 상황에 호환 내지 규격을 짓기 위해
ascii에서 나서서 code set을 정하고, byte규정을 지었을 거란 생각이...
자신이 쓴 코드 한줄, 바이트 한개가 실제 하드웨어를 구동하는 바로 그
제어코드도 되고, operand도 되는...
실체가 있는 그런 작업을 해본다는 것의 의미를 다시금 생각해볼수 있었던
좋은 답변들 감사합니다.^^;
(사실 이렇게 횡수하면서도, 제가 제대로 이해는 한건지도 모르겠습니당 ^^; )
--------------------------------------------------------------------------------
＼(´∇`)ノ ＼(´∇`)ノ ＼(´∇`)ノ ＼(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)
gLitCh1diX2님...serial programming fo
gLitCh1diX2님...
serial programming for c programmer
라는 것이 책입니까?
못 찾겠던데...책이라면 어떤 책인지
설명 좀 해 주실 수 있을런지요...
네,
그거 아마 책이름이 맞을건데요,
실은 저두 본지 꽤 된지라 제목이 확실히 그건지도 확실치는 않아요.
다만, 이미 절판된 책인데, 제 기억으론
삼각형이덩가 어디서 번역서(?)같이 나온것 같기도 하고...
그런데 그게 번역서인지, 비슷한 테마로 나온 다른 책인지도 확실치 않습니다.
누군가 보길래 조금 넘겨보니, 원서를 축약해서 번역해놨나 했던
느낌도 기억이..^^;
이 thread에서 여러 고수님들이 답변해주신 내용들이 언급되어있었던것
같아서 그렇게 적은 것이었습니다.
아마, 대학 도서관에는 있을것 같습니다.(엄청 너덜너덜해진채루요^^;)
--------------------------------------------------------------------------------
＼(´∇`)ノ ＼(´∇`)ノ ＼(´∇`)ノ ＼(´∇`)ノ
def ed():neTdiVeR in range(thEeArTh)
"C Programmer's Guide to Serial Communic
"C Programmer's Guide to Serial Communications"
이 책이 맞나요?
몇년전에 사 두었는데 선배가 빌려갔었거든요..
이 게시판을 보고 느낀바가 있어 당장 빼앗아 왔습니다... :lol:
Re: \n 과 \n\r
다들 터미널쪽으로 접근을 하시는데, 다른 관점으로 접근해봐도 재미있습니다 :)
사실상 윈도우즈에서 커맨드라인은 큰 의미가 없으니까 도스라고 해도 되긴 하지만 윈도우즈라고 해도 큰 관계는 없으니..
왜 유닉스는 줄바꿈이 \n인데 윈도우즈는 \r\n일까
왜 유닉스는 디렉토리 구분자가 /인데 윈도우즈는 \일까
왜 유닉스는 환경변수에서의 구분자가 :인데 윈도우즈는 ;일까
왜 유닉스는 환경변수 참조가 $인데 윈도우즈는 %%일까
왜 유닉스는 옵션 구분자가 -인데 윈도우즈는 /일까
(그런데 왜 vc++커맨드라인 옵션은 -도 먹을까 -_- 줏대를 지켜야지)
왜 유닉스는 cd하면 홈디렉으로 가는데 윈도우즈는 현재디렉을 보여줄까
(pwd를 만들기 귀찮았을까)
왜 유닉스는 ls인데 윈도우즈는 dir일까
왜 유닉스는 cat인데 윈도우즈는 type일까
왜 유닉스는 cp인데 윈도우즈는 copy일까
왜 유닉스는 mv인데 윈도우즈는 move일까
(그런데 왜 윈도우즈는 cd는 만들었을까 chdir있는데)
왜 유닉스는 대소문자 구별을 하는데 윈도우즈는 안할까
어떻게 윈도우즈는 copy *.JPG *.jpg가 될까 copy *.JPG *.jpeg *.jpg는 안될까?
어떻게 윈도우즈는 따옴표 없이 cd program files가 될까
생각해보면 더 나오겠지만 이것으로 그만하죠 8)
왜 똑같이 만들면 편했을 것을 다 다르게 만들었을까요 :(
Re: \n 과 \n\r
M$의 음모론..ㅡㅡ;;
사용자들이 초기에 익숙해진 운영체에서 다른운영체제로의 전환을 불편하게하여.. 사용자층을 뺏기지 않기위함
아무래도 일반사람들이 유닉스보다는 도스를 먼저 접한다는계산에서 유닉스와의 환경을 비슷하게 가져가는것은 유닉스로 쉽게 사용자를 넘겨줄우려가 있다
따라서 고의적으로도 사용자의 실수를 유도하며 그로인해 불편함을 느끼게하도록하려는음모가 있다는..
-------믿거나말거나..ㅡ,.ㅡ;
----------------------------------------------------------------------------
CP/M에서 그렇게 썼기 때문에 DOS에서 그렇게 쓰지 않았을까요?
CP/M에서 그렇게 썼기 때문에 DOS에서 그렇게 쓰지 않았을까요?
초기 DOS는 Quick & Dirty OS라는 명칭의 CP/M클론을 사들인 것이라고 들었습니다.
- 죠커's blog / HanIRC:#CN
[quote="dangsan49"]vim에서 dos형식과 unix형식을
:set fileformat=dos(or unix) 아닌가요?
----
블로그 / 위키 / 리눅스 스크린샷 갤러리
CR/LF가 machine에 따라 dependent할지도 모른다는 생각도
CR/LF가 machine에 따라 dependent할지도 모른다는 생각도 드네요. gcc machine description에서 매크로들 중에 LF와 CR을 정의하는 TARGET_NEWLINE ('\n'), TARGET_CR ('\r') 라는 매크로가 있다는 사실을 얼마전에 알았습니다.
CR, LF 는 machine dependent 하지 않고 고정되어 있습
CR, LF 는 machine dependent 하지 않고 고정되어 있습니다. ASCII 에서 정의한 것이죠
CR = ascii code 13
LF = ascii code 10
http://www.december.com/html/spec/ascii.html
---
http://coolengineer.com
[url]http://weblogs.asp.net/oldnewthing/
http://weblogs.asp.net/oldnewthing/archive/2004/03/18/91899.aspx
----
I paint objects as I think them, not as I see them.
atie's minipage
Re: \n 과 \n\r
아..다른 것들도 괜히 비슷하면서도 다른 것 같아서 좀 그런데,
디렉토리 구분자가 역슬래쉬(\)인 것은 너무 불편한 것 같아요.. ㅡ.ㅡ;;
C의 스트링에서 저 문자가 특수한 의미로 인식되다 보니 경로 나타낼려면
실제로는 "\\" 이렇게 붙여야 하니...ㅡ.ㅡ 게다가 울나라에서는 역슬래쉬가
원화 기호(W 에 줄쳐진것)로 나타나서 가독성도 팍팍~~ 떨어지고..ㅡ.ㅡ.;;
누가 왜 그렇게 되었는지 아시는 분 없나요?
이유라도 알아야 코딩할 때 MS에 신경질;;;이 덜 날 것 같네요.. :?
perl 시대가 생각 납니다.
한 5년 전에는 웹프로그램하면 perl 이였죠. 가끔 C도 있었지만,
perl이 그렇게 익숙하지 않던 당시에 웹개발자(웹마스터에 가까웠지만)이
겪는 최후의 문제 꺼리가 \r\n 문제로 기억됩니다.
저도 이 때문에 몇 일을 밤세웠던 기억이 있습니다. 에구
윈도에서 작성된 perl 프로그램을 리눅스에 이식하면
아무 것도 없는 공백라인에서 에러가 나오는 경우가 나왔지요.
이유를 전혀 알수 없어 식음전폐하고 매달렸던 기억이 납니다.
나중에 보니까 \r\n을 \n 으로 바꾸어 주던
편번이 5~6개나 나왔던 것 같은데 기억나는 것은 몇 개 안됩니다.
이 쓰레드를 읽다 보니
닥질하던 그 옛날 생각이 파도치듯 밀려 오네요.
조르바와 함께 춤을....
Re: \n 과 \n\r
아, 저도 이거 무지하게 궁금했던건데요.
어쩌다가, 하필이면, 왜, 뭐땀시,!!!!
우리나라에선 백슬래쉬가 원화 역할을 하기로 결정된거죠?
원화가 백슬래쉬 역할을 하나..아쒸..하튼요 ㅡ,.ㅡ;
옛날에 텔넷으로 보는 텍스트모드 스타워즈 영화 기억하시죠?
그 명작이 몽창 깨져서 나오는데, 진짜 열받더군요.
(물론 인코딩(?)을 바꾸면 잘 나오긴 했지만..하튼..)
프로그래밍 10년 동안
자바의 머시기머시기+Listener ( ←얘는 수천번을 쳐도 헷갈림)
와 함께 헷갈림의 양대 산맥입니다.
↑ 반농담이고, 정말 프로그래밍을 하던 뭘하던 가독성 팍팍팍 떨어지지 않을 수 없는데 대체 누가 저런 결정을 했는지 그 오(?)적(敵)들을 아시는 분 없나요? 그냥 빌 게이츠는 아닌 거 같은데 ㅡ.ㅡ
Re: \n 과 \n\r
윈도우에서 디렉토리 구분자는 DOS 시절로 거슬러 올라갑니다.
DOS 2.0 이 나올 때, 획기적으로 도입한 것이 디렉토리(!) 개념이었죠..
아마 CP/M 이나 이 녀석들의 옵션이 / 로 들어가기때문에 다른 선택을 했어야했을 것입니다.
추측성 기사는... 여기까지.. 이 글타래에 제 추측이 두번째들어가는군요.
---
http://coolengineer.com
Re: \n 과 \n\r
저도 이게 궁금해서 물어봤던 기억이....
http://bbs.kldp.org/viewtopic.php?t=32348&highlight=
저 위에있는 perky님이 답변을 주셨었군요~
아..나도 guru가 돼고파....
ㅎㅁㅎ
NVT Standard에 따르면 <CRLF>가 End of Line 표기에 사용되어야 합니다.
1985년 10월에 발표된 RFC 959의 원문을 참조하면 다음과 같습니다.
"In accordance with the NVT standard, the sequence should be used where necessary to denote the end of a line of text."
NVT Standard는 Telnet 프로토콜에서 표준으로 사용되는 8-bit NVT ASCII를 정의하는 표준입니다.
역사가 까마득하다는 뜻이겠죠? :)
NVT - Network Virtual Terminal(네트워크 가상 터미널),
Telnet 프로토콜은 rfc 854에서 처음 정의되었으며, 여기에서 8 bit NVT ASCII를 표준 문자 집합으로 사용하기로 하였습니다.
viz 님이나 ed.slownet 님 말씀처럼 라인프린터의 수직 수평이동을 위한 구분자인듯..
Unix 나오기 이전인 1964년 만들어진
CARRIAGE CONTROL (ASA) (FORTRAN) Vertical Format Control Character에 정의되기를
Character Vertical Spacing
blank Move paper up one line
0 Move paper up two lines
1 Move paper to top of next page
+ No movement, i.e., overprint
로 명시되어 있다고 하네요.
이런 접근 방법을 Vertical Format Control Characters라고 하구요.
ASCII/EBCDIC 의 Vertical Format Control Characters는 rfc 959에
"ASCII/EBCDIC vertical format controls (i.e., , , , , ) which the printer process will interpret appropriately. , in exactly this sequence, also denotes end-of-line."
와 같이 정의되어 있네요.
어떤 책에서 보니
한참 지난 타래에 쓰려니..
아무도 신경쓰지 않을 듯하여 맘대로 씁니다.
어떤 책인지 기억은 나지 않으나,,
텔레타이프에서 아스키 전송할 때.. 80칼럼 끝에서 1칼럼으로 이동하는데..
2초(아니면 두개의 문자를 전송할 시간) 정도가 필요하여 CR LF를 두었다고 하는 전설이 있습니다.
버퍼가 충분하지 않았거나 하여 텔레타이프가 글자를 찍어내는 속도와 전송속도를 동기화하기 위함이라는..
Believe Or Not!!
호떡