bash 터미널 너비 계산하기 문제

http://kldp.org/node/84184
위의 post의 답변이라고 볼 수도 있으나, 좀 더 많은 분이 봤으면 하는 생각에 새 글로 올립니다.

예전부터 bash에서 문제가 되던 것이 있었는데, 아직도 안고쳐졌네요. 문제의 원인은 알고 있는데, 아직 고쳐지지는 않았습니다.

보면 bash에서 글자들이 차지하는 너비를 잴 때 글자수로 하고 있습니다.
예를 들어서,

가나다abc

이건 여섯자입니다.

그런데 이것이 실제로 터미널에서 차지하는 영역의 크기는 아홉 칸입니다. 한글 하나가 터미널에서 두 칸을 차지하기 때문이죠. 현재 많은 프로그램이 이 처리를 잘 못하고 있습니다.

bash가 그렇고 ls를 했을때 정렬하는 것도 한글 이름의 파일이 있으면 삐뚤해지는 것을 볼 수 있습니다.

좀 더 자세히... bash에 한정해서 얘기해보겠습니다.

버그의 본질을 얘기하자면, 스트링에서 글자의 수를 재는 것과 터미널에서 차지하는 크기를 잴 때 차이를 두어야 하는데, 그렇게 하고 있지 않기 때문입니다.

bash 2.x 이하에서는 스트링에서 글자의 수를 잴 때 strlen() 류의 함수를 사용했습니다. 그렇지만 strlen() 은 단순히 바이트 수를 재는 것이기 때문에 글자 수를 정확히 재지는 못합니다. 예를들어 "가나다abc"는 여섯자이지만, strlen()으로 재면 9가 나오겠죠. (EUC-KR 환경에서 한글 한 자가 두 바이트를 차지하기 때문)

bash 3.x에서는 국제화를 적용하면서 wide character를 사용하도록 바뀌었습니다. 여기에서는 wcslen()류의 함수를 이용합니다. 이 함수는 strlen()과 다르게 글자의 수를 정확히 잽니다. L"가나다abc"를 인자로 넣으면 6이 나옵니다.

문제는 터미널 너비를 계산할 때 글자의 수를 그대로 이용한다는 것입니다.

bash 2.x 이하에서는 우연하게도 strlen()이 터미널 너비를 정확히 계산해 내었습니다. 한글 한 자가 터미널 두 칸을 차지하는 것과 한글 한 자가 두 바이트를 차지하는 것이 맞아떨어진 것이죠. (물론 한글 뿐만 아니고 일본어나 한자에서도 그렇습니다.)

그래서 비록 글자 수를 정확히 재지는 못하지만, 터미널에서의 문제는 없었습니다.

그런데 bash 3.x로 넘어가면서 터미널 너비를 계산할 때 글자의 수를 그냥 사용함으로서 문제가 발생하게 된 것입니다. "가나다abc"가 터미널에서 차지하는 수는? 하면 9 컬럼이 되어야 하는데 6으로 계산하고 있어서 문제가 발생하는 것입니다. (참고로 바이트 수는 전혀 딴 값입니다. 더이상 EUC-KR만 사용하는 것이 아니기 때문에)

해결책은. wcwidth()와 wcswidth()입니다. 이 함수는 각각 wide character, wide string이 터미널에서 차지하는 컬럼의 크기를 리턴해 주는 함수입니다. 터미널에서 차지하는 컬럼의 크기를 잴 때에는 wcslen() 대신에 위의 함수를 사용해야 합니다.

예전에 한참 bash에서 이것저것 많이 하고 불편을 겪고 시간도 많을 때 한 번 고쳐볼까 하고 본 일이 있는데, 요즘은 여건이 되질 않아서 건드리지 못하고 있습니다.

버그 리포트를 올려봤는지는 잘 기억이 나질 않네요. 버그 리포트를 올려볼까 하다가도 지금까지 말한 것을 영어로 설명하기가 빡쎄서 그만두곤 했었는데, 결국엔 올렸는지 기억이 안나네요 =_=;;

누구 한 번 뛰어들어보세요~

전 요즘 여건상, 리눅스에서 일을 하는 것도 아니고, 현재는 크게 불편을 느끼지 못하는 터라 뛰어들기가 쉽지 않네요.

제가 설명은 다 했으니, 소스코드 헤집으면서 고치기만 하면 됩니다 :)
(bash 소스가 복잡해서 고치기만 하는 것도 쉽지는 않습니다만...)