슭의 개발 블로그

Unix를 비롯한 대부분의 시스템은 LF ( \n , 0x0A )를 개행 문자로 사용하기 때문에 CR ( \r , 0x0D )을 사용하는 경우가 거의 없다. 텍스트 애플리케이션에서 진행표시줄을 만드는 것이 진행표시줄을 만드는 것이 현대 컴퓨터에서 CR 을 사용하는 거의 유일한 경우라고 볼 수 있다. CR 을 사용하면 터미널에서 진행표시줄을 간단하게 구현할 수 있다.

지난 글 에서 설명했듯이 OS X, 리눅스를 포함한 Unix를 이어받은 운영 체제는 LF (line feed, 0x0A , \n )를 개행 문자, 즉 커서를 다음 줄의 시작으로 옮기는 문자로 이용한다. 하지만 표준에 정의 된 LF 의 동작은 커서를 다음 줄로 내리는 것일 뿐, 커서를 줄의 처음으로 이동하지 않는다. 파일을 항상 운영 체제에 종속적인 애플리케이션을 통해서만 접근한다면 표준과 다른 동작은 문제되지 않는다. 하지만 파일과 입출력의 구분이 없는 유닉스 계열에서 파일과 프로세스의 입출력이 상호작용할 때 이 차이는 문제될 수 있다. 이 차이를 다루기 위해서 터미널은 출력에 적절한 가공을 하여 출력한다. 이를 제어하기 위한 플래그가 POSIX.1 표준이 정의 하는 termios 구조체의 c_oflag 다. c_oflag 는 터미널이 받은 문자를 출력하기 전에 어떤 후처리를 할지에 대한 플래그다. c_oflag에서 가장 중요한 플래그는 OPOST 다. 이는 입력에 대한 후처리를 할지 말지에 대한 플래그로 OPOST 가 꺼져있으면 다른 플래그와 상관없이 터미널은 받은 문자열을 그대로 보여준다. 이 플래그를 끄는 경우는 거의 없다. 하지만 터미널을 텍스트를 보여주기 위한 용도가 아닌 바이너리 데이터를 전송하기 위해 사용하는 경우 끄는 것이 좋다. 터미널이 Unix 계열 운영 체제에서 원하는대로 동작할 수 있게 해주는 플래그는 ONLCR 이다. ONLCR 이 켜져 있으면 터미널은 출력을 해석할 때 NL 을 CRNL 로 해석한다. 즉, Unix에서도 ONLCR 이 꺼져있다면, LF 를 만났을 때, 다음 줄의 처음으로 이동하는 것이 아닌, 현재 위치의 다음 줄로 이동한다. Unix 계열 운영 체제에서 윈도우에서 만들어진 파일을 출력해야 할 경우, CRNL 을 NL 로 바꾸지 않고도 ONLCR 플래그를 끄는 것 만으로도 간단하게 출력할 수 있다. 이외에도 구형 Mac OS 처럼 동작하게 해주는 OCRNL 플래그나 탭문자( 0x09 , \t )를...

개행 문자는 멀티 플랫폼에서 작업하는 사람들을 귀찮게 하는 것 중 하나다. Mac OS, Windows, Linux는 모두 다른 문자를 개행 문자로 사용한다. 심지어 Mac OS는 과거 버전과 최신 버전에서의 동작이 또 다르다. 이번 글에서는 시스템별로 다른 개행 문자를 사용하는 원인을 살펴볼 것이다. ISO 6429 표준 에 따르면 LF (line feed, \n)는 커서를 현재 행을 유지하면서 다음 줄로 옮기고, CR (carriage return, \r)는 커서를 현재 라인의 처음으로 옮긴다. 우리가 원하는 개행 문자의 동작을 위해서는 CR 과 LF 를 함께 써야 한다. 이런 구분은 라인을 바꾸는 동작과, 커서를 처음으로 옮기는 동작이 구분된 초기 프린터나 타자기의 동작을 모방했기 때문이다. A B 즉, 표준에 따르면 " A\nB "라는 문자열은 위에 보인 예시대로 A 아래 바로 B 가 오는 것이 아니라, A 의 대각선 아래 B 가 와야 한다. 하지만 개행 문자로 CRLF 를 사용하는 시스템은 드물다. 지금은 스토리지가 매우 싼 자원이다. 하지만 과거에는 스토리지가 매우 비싼 자원이었다. 이 시절 시스템 설계자들은 개행 문자를 위해 2바이트나 할당하라는 것을 과도한 사치로 보았다. 결국 어떤 시스템 설계자는 LF 를 어떤 시스템 설계자는 CR 을 단독으로 개행 문자로 사용하기 시작했다. 그 와중에도 표준을 지키던 시스템이 있었다. 그중 하나는 CP/M 이라는 운영체계다. CP/M은 CR 과 LF 의 조합을 개행문자로 사용했다. 이는 단순히 표준을 지키고자 하는 의지 때문이 아니라, 과거 있었던 원격 터미널 장치와의 호환성을 유지하기 위한 전략적 선택이었다. 다른 말로 하면, 비싼 스토리지 비용을 감당하더라도 호환성을 유지해 시장을 장악하는 것이 유리하다는 판단이었다. 후에 나오는 몇몇 운영체제도 CP/M 과 같은 선택을 했고, 이 중 하나가 마이크로소프트의 MS-DOS였다. 이 선택이 지금까지 이어져 마이크로소프트의 ...

escape code의 ISO 6429 에서 정의된 정확한 명칭은 control function이다. control function을 표현하는 코드 혹은 시퀀스를 흔히 escape code라고 말한다. ISO 6429 가 정의하는 컨트롤 코드는 모양에 따라 C0 코드와 C1 코드로 나누어진다. C0 코드는 ASCII Table에서 non-printing 문자에 해당하는 코드이다. 아마 Escape Codes 중 개발자들에게 가장 익숙한 코드일 것이다. 라인 피드( \n ), 캐리지 리턴( \r ), 탭( \t ), 널 문자( \0 ) 등이 여기에 해당한다. C1 코드는 0x80 에서 0x9F 사이 32개의 1바이트 값으로 표현되는 코드다. C0와 다르게 C1 코드는 ASCII 에 정의된 값이 아니다. ASCII 만 지원하는 터미널, 다시 말해 7비트 환경에서만 사용할 수 있고, 8비트 환경인 현대 터미널에서는 사용될 수 없다. 그래서 현대 터미널은 대부분 C1 코드가 필요할 때 escape sequence로 표현한다. escape sequence란 말 그대로 ESC 를 시작으로 하는 일련의 문자열을 의미한다. 그중 C1 코드와 같은 기능을 하는 시퀀스는 첫 바이트가 ESC ( 0x1B )이고 두 번째 바이트가 @ ( 0x40 )에서 _ ( 0x5F )로 이루어지는 두 바이트의 시퀀스다. 예를 들면 IND 는 8비트 환경에서는 0x84 로 표현되지만 7비트 환경에서는 ESC D ( 0x1B 0x44 )로 표현된다. 이 두 번째 바이트는 Final character of Escape sequence 라는 의미로 Fe 라고 불리며, 두 바이트로 표현된 C1 코드를 Fe sequence 라고 부르기도 한다. ISO 6429 가 정의하는 escape sequence는 Fe sequence 이외에도 더 있다. 예를 들면 ` ( 0x60 )에서 ~ ( 0x7E ) 사이의 값은 Fs 라고 불리며, ESC 다음 Fs 가 따라오는 시퀀스는 Fs sequenc...

개발을 위해 컴퓨터에 리눅스를 설치할 때 반드시 설치하는 프로그램이 있다. 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.wik...

다른 Iterator (a.k.a 반복자)를 받아 새로운 반복자를 반환하는 함수를 iterator adapter 라고 부른다. adapter라는 이름은 GoF의 디자인 패턴 중 하나인 adapter pattern 에서 온 말이라고 한다. 그런데 실제로는 adapter pattern보다는 decorator pattern 에 해당하기 때문에 이름을 신경쓰면 용도를 헷갈릴 수 있다. 그러니 이름에 대해서는 크게 신경 쓰지 않는 것이 좋다. 이름에 대한 불평은 그만하고 iterator adapter가 무엇을 하는가? iterator adapter는 반복자가 순회하면서 할 일을 더해준다. 무슨 말인지는 실제 구현체를 보면 쉽게 이해할 수 있을 것이다. map 함수는 대표적인 adapter다. 함수형 언어를 써본 사람이라면 많이 익숙할 map 함수가 반환하는 반복자는 기존의 값을 새로운 값으로 변환한 값을 순회한다. 이 외에도 표준 라이브러리에 이미 다양한 adapter가 구현돼있다. 이중 가장 많이 사용되는 것은 반복문과 같이 사용하기 좋은 adapter들이다. 조건을 만족하는 값만 돌려주는 filter , 지정 된 몇 개의 값만 반환하는 take , 반대로 몇 개의 값은 생략하고 반환하는 skip , 몇 개씩 값을 건너뛰며 순환하는 step_by 와 같은 adapter가 대표적인 예시다. 이런 adapter를 반복문과 함께 사용하면 복잡한 조건 처리를 쉽게 표현할 수 있다. 이 외에도 영원히 종료하지 않고 순환하게 만드는 cycle 이나, 순환하는 값에는 변환을 주지 않고, 사이드이펙트를 발생시키기만 하는 inspect 도 많이 사용된다. adapter를 사용할 때 주의해야 할 점이 하나 있다. adapter가 반환하는 것 역시 반복자일 뿐이다. 실제로 반복자를 사용하기 전에는 adapter가 지정한 일을 수행하지 않는다. 쉽게 말해 실제로 값이 필요할 때까지 실행을 미루는 lazy evaluation 을 한다는 것이다. 따라서 아래와 같은...

최적화는 귀찮다. 눈에 띄는 실수를 한 게 아니면 어떻게 고쳐야 할지 감이 오지도 않고, 대부분의 최적화는 가독성을 떨어뜨리기 때문에 버그가 발생할 확률이 늘어난다. 하지만 어떤 최적화 테크닉은 코드를 크게 수정하지 않고 큰 성능 향상을 가져온다. 메모이제이션 이 그 대표적인 예제다. 계산이 무겁거나, 디스크의 값을 읽거나, 네트워크 통신처럼 근본적으로 시간이 오래 걸리는 일은 그 실행 결과를 저장했다 재사용하는 것만으로 큰 성능향상을 가지고 온다. 파이썬은 메모이제이션을 쉽게 적용할 수 있는 데코레이터 를 제공한다. functools 모듈의 lru_cache 데코레이터 가 이것이다. 이 데코레이터를 붙이면 함수의 실행 결과를 캐싱해준다. 캐시의 크기는 maxsize 로 지정할 수 있다. 저장할 실행 값이 이 개수를 넘어가는 경우 LRU 알고리즘 에 따라 가장 오래전에 사용한 결과를 지우고 새 값을 캐싱한다. lru_cache 를 사용하면 쉽게 최적화할 수 있지만 아무 함수에나 사용할 수 있는 건 아니다. 함수의 인자를 캐시키로 사용하기 때문에 함수의 실행 결과가 함수의 인자 이외에 다른 요소에 의존적인 함수에는 사용하지 못한다. 즉, 랜덤 요소가 들어가거나 시간에 따라 결괏값이 변하는 함수에는 사용하면 안 된다. 결정성이 보장되는 함수에만 사용할 수 있다는 것은 모든 캐시의 공통적인 특성이다. 여기에 더해 파이썬이 제공하는 lru_cache 는 그 구현상의 문제로 한 가지 제약이 더 있다. 이 데코레이터는 값을 저장하기 위해 인자를 키로 가지는 dictionary 를 사용한다. 따라서 모든 인자가 hashable 타입이어야 한다. 다시 말해 mutable 하지 않은 dictionary, set, list 등을 인자로 받는 함수는 이 데코레이터를 사용해 캐싱할 수 없다. 이런 타입을 인자로 받던 함수는 그 인자를 frozenset 이나 tuple 같은 immutable 타입으로 변환해야 한다. 게다가 keyword argument 를...