<div id="readability-page-1" class="page"><div data-version="2" id="Blog1">
<article>
<div>

<h3>
Escape Codes의 역사
</h3>


<div id="post-body-8044891909182484927">
<p>개발을 위해 컴퓨터에 리눅스를 설치할 때 반드시 설치하는 프로그램이 있다. <a href="https://github.com/mtoyoda/sl" target="_blank"><code>sl</code></a>이라는 프로그램이다. 이게 무슨 프로그램이냐면 커맨드 창에서 <code>sl</code>을 치면 기차를 보여주는 프로그램이다. 실용성 있는 프로그램은 아니고, 터미널에서 많이 사용되는 <a href="https://man7.org/linux/man-pages/man1/ls.1.html" target="_blank"><code>ls</code></a> 명령어의 오타를 냈을 때 화면에 기차를 보여줘 생각할 시간을 주는 프로그램이다. 이를 통해 오타를 낼 정도로 마음이 급한 상황에서 다른 실수를 하지 않고 조금은 침착해지라는 의미에서 항상 설치한다.</p>



<p>터미널은 실행한 프로그램이 내보내는 두 출력 <code>stdout</code>과 <code>stderr</code>를 받아 화면에 보여주는 프로그램이다. <code>stdout</code>과 <code>stderr</code>은 순차적인 출력이다. 보통의 출력은 왼쪽 위에서 오른쪽 아래로 흘러간다. <code>sl</code>처럼 이미 쓰인 화면에 새로운 글자를 그리기 위해서는 특별한 방법이 필요하다. 이 특별한 방법은 <a href="https://en.wikipedia.org/wiki/ANSI_escape_code" target="_blank">escape codes</a>라고 한다.</p>

<p>escape codes는 터미널에 정의된 일종의 약속이다. 이 약속은 현재는 <a href="https://www.iso.org/standard/12782.html" target="_blank"><i>ISO 6429</i></a>에서 정의하는 표준을 따른다. 하지만 과거에는 통일된 규정이 없이 터미널 모델마다 다른 규정을 가지고 있었다. 과거의 컴퓨터를 모르면 터미널 모델마다 다르다는 것이 이해되지 않을 수도 있다. 이를 알기 위해서는 컴퓨터의 역사를 알아야 한다.</p>

<p>지금은 터미널이라고 하면 <a href="https://en.wikipedia.org/wiki/Command-line_interface" target="_blank">CLI</a>를 위한 애플리케이션을 의미한다. 하지만 과거 터미널은 문자 그대로 컴퓨터의 최종 단말기였다. 이 단말기는 <a href="https://en.wikipedia.org/wiki/Mainframe_computer" target="_blank">메인프레임 컴퓨터</a>에 연결돼 메인프레임 컴퓨터의 입출력을 담당했다. 현대의 터미널 앱이 <a href="https://en.wikipedia.org/wiki/Terminal_emulator" target="_blank">터미널 에뮬레이터</a>라고 불리는 이유가 이 터미널을 에뮬레이트 하는 것이기 때문이다. 과거 터미널은&nbsp;<a href="https://en.wikipedia.org/wiki/ADM-3A" target="_blank"><i>ADM-3A</i></a>, 지금도 유명한 IBM 사의&nbsp;<a href="https://en.wikipedia.org/wiki/IBM_2260" target="_blank"><i>IBM 2260</i></a>과 <a href="https://en.wikipedia.org/wiki/IBM_3270" target="_blank"><i>IBM 3270</i></a>, 후에 HP에 인수되는 <a href="https://en.wikipedia.org/wiki/Digital_Equipment_Corporation" target="_blank"><i>DEC</i></a> 사의 VT 시리즈 등 다양한 회사에서 개발됐고, 이들은 각각 고유의 표준을 가지고 터미널을 조정했다.</p>



<p>독립적으로 구현됐던 코드들은 호환되지 않았고, 이들을 통일하기 위한 작업이 1970년대에 진행됐다. 첫 표준은 1976년 출시 된 <a href="https://www.ecma-international.org/publications-and-standards/standards/ecma-48/" target="_blank"><i>ECMA-48</i></a>이었다. 하지만 현대의 escape codes에 가장 큰 영향을 끼친 건 1978년 DEC에서 출시한&nbsp;<a href="https://en.wikipedia.org/wiki/VT100" target="_blank"><i>VT100</i></a>이라는 터미널이다. <i>VT100</i>은 <a href="https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_(Control_Sequence_Introducer)_sequences" target="_blank">Control Sequence Intdoducer</a>(a.k.a. CSI)를 도입하여 다양한 명령어를 도입했다. 여기에는 커서의 이동, 스크롤 등 현대 터미널 에뮬레이터에도 쓰이는 중요한 기능이 포함된다. <i>VT100</i>의 구현을 기반으로 1979년 ANSI에서 <i>ANSI X3.64</i> 표준을 발표했고, <i>ECMA-48</i>과 <i>ANSI X3.64</i>를 기반으로 1983년 ISO에서 <a href="https://www.iso.org/standard/12780.html" target="_blank"><i>ISO 6429</i></a>를 발표. 1992년 몇 가지 코드를 추가해 지금까지 표준으로 사용되고 있다. 따라서 현대의 터미널 에뮬레이터들은 모두 ISO 6429를 따라 구현됐다고 보면 된다.</p>
</div>

</div>


</article>
</div><div data-version="2" id="PopularPosts1">
<h3>
이 블로그의 인기 게시물
</h3>
<div role="feed">
<article role="article">
<h3><a href="https://blog.seulgi.kim/2014/01/raii.html">RAII는 무엇인가</a></h3>

<div>
<p>
&nbsp; RAII 는 C++에서 자주 쓰이는 idiom으로 자원의 안전한 사용을 위해 객체가 쓰이는 스코프를 벗어나면 자원을 해제해주는 기법이다. C++에서 heap에 할당된 자원은 명시적으로 해제하지 않으면 해제되지 않지만, stack에 할당된 자원은 자신의 scope가 끝나면 메모리가 해제되며 destructor가 불린다는 원리를 이용한 것이다.  &nbsp;원래는 exception 등으로 control flow가 예상치 못하게 변경될 때를 대비하기 위해서 쓰이던 기법이다.   &nbsp;아래의 예제를 보자.   &nbsp;첫 번째 코드는 위험하다.&nbsp;thisFunctionCanThrowException() 함수에서 exception을 발생시킨다면 resource를 해제하지 못한다.  두 번째 코드는 일단은 resource를 해제하고 있다. 하지만 보기에 좋은 코드는 아니다. 그리고 유지하기도 어려워진다.  세 번째 코드는 RAII를 위해 c++ 11의 스마트 포인터인 unique_ptr을 이용하는 방법이다. unique_ptr은 소멸할 때 자신이 들고 있는 메모리를 해제시켜주기 때문에 함수 밖으로 나가면 resource가 해제되는 것이 보장된다.   &nbsp;여기서 말하는 자원은 단순히 heap 메모리만을 말하는 것이 아니다. heap 메모리 이외에도 파일이나 db와 같은 것들도 전부 RAII를 이용해 안전하게 사용할 수 있다.  여기에 더 나아가서 특정 scope를 벗어나면 반드시 실행돼야 하는 코드들도 RAII를 이용해 처리할 수 있다. 즉, 다른 언어에서 finally에 해당하는 구문을 RAII를 이용해서 처리할 수 있다. 실제로 C++의 아버지이자 RAII라는 용어를 처음 만든&nbsp;Bjarne Stroustrub는 c++에 finally를 집어넣지 않는 이유를&nbsp; "RAII가 있는데 굳이 있을 필요가 없다." 라고 말하고 있다.
</p>
</div>
</article>
<article role="article">
<h3><a href="https://blog.seulgi.kim/2014/04/log-aggregator-scribe-flume-fluentd.html">Log Aggregator 비교 - Scribe, Flume, Fluentd, logstash</a></h3>

<div>
<p><a href="https://blog.seulgi.kim/2014/04/log-aggregator-scribe-flume-fluentd.html">
<img alt="이미지" sizes="72px" src="https://4.bp.blogspot.com/-j7i9ff1Ezqg/U08scDM0IaI/AAAAAAAAAkM/UmgxME1ZsKw/s1600/2011121301081683.jpg">
</a>
</p>
<div>
<p>
https://docs.google.com/presentation/d/12A5RlMCVDN6tA_zUnLrZ0TN5v08gz2GhlRdzxy3T3mU/edit?usp=sharing  &nbsp;회사에서 최근에 Log aggregator system으로 무엇을 사용해야 할지 조사해본 자료다.  &nbsp;우선 log aggregator가 무엇인지 한 문장으로 설명하면, 여러 머신에서 쌓인 로그들을 한 번에 분석할 수 있도록 수집하여 주는 시스템을 말한다.  &nbsp;요새는 특히나 클라우드 시스템이 유행하면서 같은 일을 하는 시스템임에도 다른 머신에서 돌아가는 일이 많아지면서 필요성이 크게 증가하였다.  이번 조사로 알게 된 것들을 적어보도록 하겠다.   Scribe &nbsp;우선 scribe 는 Facebook에서 제작하고 사용하던 log aggregator system이다.    scribe:&nbsp; http://www.cnblogs.com/brucewoo/archive/2011/12/13/2285482.html  &nbsp;후에 다른 로그 수집 시스템들을 보면 알겠지만, Scribe는 다른 시스템보다 간단한 구조로 되어 있다.   &nbsp;Scribe는 일종의 message queue와 message queue에 쌓인 message를 DB에 저장해 주거나, DB가 실패하였으면 local에 저장하였다가 DB가 복구되었을 때 다시 DB에 저장해 주는 것만을 책임진다. 다시 말하면, message queue에 실제로 메시지를 보내는 부분은 사용자가 직접 작성하여야 한다는 것이다.   &nbsp;흔히들 말하는 scribe의 장점은 c++로 만든 만큼 다른 시스템들의 3~5배 정도의 성능을 보여준다는 것이다. 하지만 실제 scribe 사용자들은 무엇보다도 Facebook이 실제로 사용하였던 솔루션인 만큼 성능과 안정성에서 신뢰도가 있다는 것을 장점으로 뽑는다.   &nbsp;하지만 나는 scribe를 사용하는 것을 추천하지는 않는다.  &nbsp;일단 가장 큰 문제는 더이상 Facebook이 Scribe를 사용하지 않는다는 것이다. Faceboo
</p>
</div>

</div>
</article>
<article role="article">
<h3><a href="https://blog.seulgi.kim/2015/11/cpp-enum-class.html">[C++] enum class - 안전하고 쓰기 쉬운 enum</a></h3>

<div>
<p>
&nbsp; C++ 03 까지의 enum 은 여러 가지 문제를 가지고 있었다. 그래서 그 문제들을 해결하기 위해 C++ 11은 enum class 라는 것을 새로 만들었다. 이제부터 기존의 enum 에 어떤 문제가 있었고, 이것을 enum class 에서 어떻게 해결하였는지 살펴볼 것이다.   &nbsp;우선 기존의 enum 은 전방 선언할 수 없었다. 그 이유는 enumerator에 어떤 값이 들어있을지 알 수 없으면 그 크기를 정할 수 없기 때문 이다. 하지만 enum class 는 underlying type을 명시하지 않으면 int  타입과 같은 크기의 변수로 선언되고, int  값 안에 들어가지 못할 값을 지정하면 컴파일 에러를 발생시킨다.  &nbsp;만약 int 를 벗어난 범위의 값을 사용하고 싶다면, underlying type을 명시해주어야 한다.    &nbsp;기존 enum 의 또 다른 문제는 enumerator의 이름의 범위가 한정되지 않는다는 것이다. 예를 들어 아래와 같은 코드를 보자.   &nbsp;IO 함수의 결과와 Parse 함수의 결과를 enum 으로 표현해 보았다. 하지만 이 코드는 컴파일되지 않는다. IOResult 의 Error , Ok 가 ParseResult 의 Error , Ok 와 겹치기 때문이다. 이를 해결하기 위해서는 다음과 같이 enumerator의 이름을 다르게 하거나    &nbsp;아래와 같이 namespace를 이용해야 했다.   &nbsp;&nbsp; 하지만 enum class 는 enumerator의 이름이 enum class  안으로 한정되기 때문에 이런 복잡한 과정이 필요 없이 그저 enum class 를 선언하여 사용하면 된다.    &nbsp;무엇보다 기존 enum 의 가장 큰 문제는 정수형 변수로 암시적으로 변환되는 약 타입(weak type)  변수라는 것이다. 하지만 enum class 는 정수형 변수로 암시적 변환이 되지 않는다. enum class 를 정수형 변수처럼 사용하려고 하면 컴파일 에러를 발생시킨다. 만약 정수형 변수로 사용하고 싶으면 static_cas
</p>
</div>
</article>
</div>
</div></div>

슭의 개발 블로그

개발을 위해 컴퓨터에 리눅스를 설치할 때 반드시 설치하는 프로그램이 있다. sl이라는 프로그램이다. 이게 무슨 프로그램이냐면 커맨드 창에서 sl을 치면 기차를 보여주는 프로그램이다. 실용성 있는 프로그램은 아니고, 터미널에서 많이 사용되는 ls 명령어의 오타를 냈을 때 화면에 기차를 보여줘 생각할 시간을 주는 프로그램이다. 이를 통해 오타를 낼 정도로 마음이 급한 상황에서 다른 실수를 하지 않고 조금은 침착해지라는 의미에서 항상 설치한다.
 
출처: https://github.com/mtoyoda/sl
 터미널은 실행한 프로그램이 내보내는 두 출력 stdout과 stderr를 받아 화면에 보여주는 프로그램이다. stdout과 stderr은 순차적인 출력이다. 보통의 출력은 왼쪽 위에서 오른쪽 아래로 흘러간다. sl처럼 이미 쓰인 화면에 새로운 글자를 그리기 위해서는 특별한 방법이 필요하다. 이 특별한 방법은 escape codes라고 한다.
 escape codes는 터미널에 정의된 일종의 약속이다. 이 약속은 현재는 ISO 6429에서 정의하는 표준을 따른다. 하지만 과거에는 통일된 규정이 없이 터미널 모델마다 다른 규정을 가지고 있었다. 과거의 컴퓨터를 모르면 터미널 모델마다 다르다는 것이 이해되지 않을 수도 있다. 이를 알기 위해서는 컴퓨터의 역사를 알아야 한다.
 지금은 터미널이라고 하면 CLI를 위한 애플리케이션을 의미한다. 하지만 과거 터미널은 문자 그대로 컴퓨터의 최종 단말기였다. 이 단말기는 메인프레임 컴퓨터에 연결돼 메인프레임 컴퓨터의 입출력을 담당했다. 현대의 터미널 앱이 터미널 에뮬레이터라고 불리는 이유가 이 터미널을 에뮬레이트 하는 것이기 때문이다. 과거 터미널은 ADM-3A, 지금도 유명한 IBM 사의 IBM 2260과 IBM 3270, 후에 HP에 인수되는 DEC 사의 VT 시리즈 등 다양한 회사에서 개발됐고, 이들은 각각 고유의 표준을 가지고 터미널을 조정했다.
 
출처: https://en.wikipedia.org/wiki/IBM_2260
 독립적으로 구현됐던 코드들은 호환되지 않았고, 이들을 통일하기 위한 작업이 1970년대에 진행됐다. 첫 표준은 1976년 출시 된 ECMA-48이었다. 하지만 현대의 escape codes에 가장 큰 영향을 끼친 건 1978년 DEC에서 출시한 VT100이라는 터미널이다. VT100은 Control Sequence Intdoducer(a.k.a. CSI)를 도입하여 다양한 명령어를 도입했다. 여기에는 커서의 이동, 스크롤 등 현대 터미널 에뮬레이터에도 쓰이는 중요한 기능이 포함된다. VT100의 구현을 기반으로 1979년 ANSI에서 ANSI X3.64 표준을 발표했고, ECMA-48과 ANSI X3.64를 기반으로 1983년 ISO에서 ISO 6429를 발표. 1992년 몇 가지 코드를 추가해 지금까지 표준으로 사용되고 있다. 따라서 현대의 터미널 에뮬레이터들은 모두 ISO 6429를 따라 구현됐다고 보면 된다.

Escape Codes의 역사

댓글