TL;DR
둘 중 하나 택일. (그러나 alias 쪽에 한 표를 던진다.)
- .zshrc 에
export LC_COLLATE="C"추가. alias n3='LC_COLLATE=C nnn'
macOS 고유 프로그램(GUI)이라든가, CLI 용 프로그램을 써도 오픈소스가 아닌, 역시나 Apple 만들어 제공하는 프로그램들이라면, Locale 에 따른 문제가 발생하지는 않는 듯 하다. 또, 다른 글에서도 언급했지만, 오픈소스라고 해서 다 이런 문제가 생긴다고 볼 수도 없다. 아마도 어떤 라이브러리를 사용하느냐에 따라 조금은 이상한 현상이 생길 수도 있는 모양이다.
이 내용은, 지금까지 찾아낸 바에 따르면, nnn 에서만 발생하며, macOS/Linux 모두에서 조금씩 문제가 있다.
그럼, 어떤 문제가 있나? 먼저 macOS 쪽부터.
macOS 와 nnn
macOS 에서 한국어를 선택하면, 기본 로캘은 다음과 같다.
$ locale LANG="ko_KR.UTF-8" LC_COLLATE="ko_KR.UTF-8" LC_CTYPE="ko_KR.UTF-8" LC_MESSAGES="ko_KR.UTF-8" LC_MONETARY="ko_KR.UTF-8" LC_NUMERIC="ko_KR.UTF-8" LC_TIME="ko_KR.UTF-8" LC_ALL=
그런데, 이 상태로는, 특정 프로그램에서 정렬에 문제가 생긴다. 그게 nnn 이었다.
이걸 해결하려면, LC_COLLATE 만 ‘C’ 로 바꿔준다. 이거 저거 실험해봤는데, C 만 의미가 있었다.
즉, 이런 상태가 돼야 정렬에 문제가 없다.
$ locale LANG="ko_KR.UTF-8" LC_COLLATE="C" LC_CTYPE="ko_KR.UTF-8" LC_MESSAGES="ko_KR.UTF-8" LC_MONETARY="ko_KR.UTF-8" LC_NUMERIC="ko_KR.UTF-8" LC_TIME="ko_KR.UTF-8" LC_ALL=
이를 위해서, .zshrc 에 저 항목을 export 로 넣어주거나, 아니면 nnn 을 스크립트, 또는 alias 화하여 사용하는 방법도 있겠다.
# .zshrc export LC_COLLATE="C" # alias alias n3='LC_COLLATE=C nnn'
어느 쪽이 더 ‘현명한’ 선택인지는 모르겠다. (그냥 똑같지 않을까?)
locale 이 정렬에 영향을 미치는 프로그램은 nnn 이 유일하다. 이런 저런 프로그램들(mc, ranger, vifm, gnu-ls, exa, lf, Double Commander(GUI))을 기본 로캘(ko_KR.utf8) 하에서 시험해봤지만, 아예 정렬 기능에 뭔가 문제가 있어보이는 vifm 을 빼고는 모두 다 정상 작동했다.
저 프로그램들 모두 LC_COLLATE=”C” 상태에서도 잘 작동했으니, 설정을 바꿔줘도 문제가 되지는 않으리라 생각한다.
또 하나, 정렬 말고도 이상한 점이 있다.
macOS 기본 터미널과 iTerm 모두, 화면을 좀 키우고(205×58 정도 크기), 한글이 포함된 디렉토리를 이동하다보면, 이상한 공백이 들어가 있기도 하고, 글자가 겹쳐지는 현상이 보이기도 한다.
화면 맨 위, 디렉토리 표시 행에, ~/Shared_Resilio/정렬연습-macOS /연습용2 라고 돼 있는데, 공백이 없어야 맞다. 터미널 창을 작게 설정해놓으면 이런 현상이 없는데, 어느 정도 커지면 이런게 보인다. 물론, 정렬은 엉망이다.
이런 식으로 글자가 겹쳐지는 현상도 있다.
역시 맨 윗줄, 연습용2/연습용2 로 글자가 중복돼 있다. 아마도, 디렉토리 이동시 화면을 다시 그리는(Refresh?) 작업이 제대로 이뤄지지 않는 듯 한데..
저 상황까지 회피할 방법은 찾지 못했다. 게다가 저 현상은 늘 나타나질 않기도 해서, 그냥 그러려니 하는 수밖에 없을 듯. (왜 맥은 이 모양일까??)
그런데, 이런 현상, macOS 용 CLI 에선 비일비재하다. mc 는 한글이 있으면 세로 줄이 제대로 정렬되지 않는 현상이 있고, ranger 도 비슷하다. vifm 도 비슷한 상황이니, 그나마 nnn 이 가장 쓸만한 편이라고 할 수 있겠다.
이걸 어떻게 알아냈을까?
macOS 설정 – 일반 – 언어 및 지역 – 응용 프로그램 에서, 프로그램별 언어 설정을 해줄 수 있다. 여기서 터미널을 English 로 정해주고,
터미널을 실행한 뒤 locale 을 확인하면 다음과 같다.
$ locale LANG="" LC_COLLATE="C" LC_CTYPE="UTF-8" LC_MESSAGES="C" LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_ALL=
흠..?? 좀 요상한 설정으로 바뀌었는데, 아무튼 저기서 정렬에 관련될 듯한 내용은 COLLATE 뿐이라, 그것만 바꿔봤더니 nnn 에서 정렬이 제대로 작동했다. 이 내용은 nnn 에 보고를 하다가 알게 됐다. 만약 LC_CTYPE 마저 C 가 돼버리면, 영문자외엔 표시가 되지 않는다.
또 한가지 재미있는 증상(?).
Double Commander 는, 그냥 일반 실행(Spotlight 나 직접 실행 등등)을 하면 정렬에 문제가 없지만, 터미널에서 open . -a 'double commander' 로 돌리면 LC_COLLATE=ko_KR.UTF-8 을 적용받아 nnn 처럼 제멋대로인 상황을 보여준다.
nnn 제작진 중 한 명인 N-R-K 는, 도대체 왜 이런 현상이 발생하는지 갈피를 잡지 못하겠다고 했는데.. 그 친구들이 모르는데 내가 어찌 알까.
마지막 한가지. nfc/nfd
애플의 큰 문제인 nfd. 왜 굳이 지들만 이걸 쓰기로 했는지는 알 수가 없다. 영어권에선 별 문제가 안되는 듯 하지만, 특히나 한국어/한글은 이 문제가 사람을 짜증나게 할 때가 많다.
다음을 보자.
정렬에 문제가 없는 듯 보이지만..??엄청나.txt 가 맨 위에 정렬이 돼 있다.
이유는??
나머지는 다 nfc 고, 엄청나.txt 만 nfd 라 그렇다. 이상한게, 내가 가진 거의 모든 CLI 도구는 대부분 위와 같은 결과를 보여줬다. 즉, 엄청나.txt 만 위에 있고, 나머지는 제대로 정렬되었다. gnu-ls, exa, ranger, Double Commander 모두 동일했다. 단지, M.C 만 nfc/nfd 관계없이 제대로 정렬된 모습을 보여줬다. macOS 전용 GUI 도구들에선 nfc/nfd 간 정렬 문제는 없었다. nfc 와 nfd 가 섞여있어도 아무 이상이 없었다.
이 문제를 잘 모르겠는데.. macOS 전용 프로그램들은 파일을 생성(저장)했을 때 nfd 형식을 취한다. 헌데, 범용 프로그램(?) 중에선 nfc 인 것들도 있다. VS Codium 이 이런데.. 이게 어디 설정하는게 있는건지??
** nfc/nfd 확인은 어떻게?
변환은 convmv 로 하지만, 확인은 unicode-nfd2c 로 할 수 있다.
Linux 와 nnn
Linux 에선 macOS 와 동일한 현상은 나타나지 않는다. 하지만 여기엔 뭔가 좀 더 복잡한 사정이 깔려있었다. 이 글에 덧붙이기엔 내용이 좀 복잡해서 따로 글을 올렸다.
RSS - Posts