sed 에서 점 (dot) 매칭하기

sed 기본정규식의 dot (.) 매칭의 설명을 보면

.
Matches any character, including newline.

이라고 되어 있는 것으로 봐서는 locale 에 따라서 적절하게 한 *글자*를 매칭시켜 줘야 할 것 같은데

EUC-KR, CP949, EUC-JP 등 locale을 변경시켜봐도 한 글자가 아니라 한 바이트를 매칭시키는 것 같습니다.

사용한 정확한 LC_ALL 은

ko_KR.cp949
ko_KR.EUC-KR
ja_JP.euc
ja_JP.EUC-JP

등입니다.

그래서 한 바이트만 매칭되도록 동작하나보다 생각했더니 utf-8 에 대해서는 한 바이트가 아니라 한 글자로 매칭시키는 결과를 보여줬습니다.

% man sed 의 매뉴얼 페이지를 보면

REGULAR EXPRESSIONS
POSIX.2 BREs should be supported, but they aren't completely because of performance problems. The \n sequence in a regular expression matches the newline character, and similarly for \a,
\t, and other sequences.

라고 되어 있어서

Posix BRE (Basic regular expression) 페이지를 쫓아가보면

9.3.4 Periods in BREs

A period ( '.' ), when used outside a bracket expression, is a BRE that shall match any character in the supported character set except NUL.

라고 되어 있어서 character set 또는 인코딩에 따라서 character를 해석해야 할 것 같은데 동작이 이상합니다.

Performance 의 문제 때문이라면 왜 utf-8은 바이트가 아니라 문자 단위로 해석되는가가 대답이 되지 않네요.

이 문제를 보고 있는 이유는 현재 리뷰중인 코드중에

ko_KR.cp949 로 LANG을 맞춰놓고, sed에서 17바이트의 문자열을 변경하기 위해서
s/.\{17\}/do something/
과 같은 식을 쓰고 있어서입니다.

cp949이건, EUC-KR 이건 다 제대로 동작하는 것을 확인은 했는데,
(일단 해당 locale들이 valid한 것은 확인되었습니다.)

이게 보장된 행동인지, 아니면 sed 의 잘못된 동작에 의존한 코드인지가 확실치 않아서

locale을 C 로 변경해서 하는 것이 어떻겠느냐라는 리뷰를 써야할지 말아야할지 망설여지고 있습니다.

아래 테스트 한 파일들을 첨부했습니다. 혹시 관심있는 분들 한번 봐 주시기 바랍니다.

테스트한 명령은 대략

% LC_ALL=ko_KR.EUC-KR sed -e 's/^.\{10\} .\{5\}/Seoul/' euckr.txt

정도입니다.

$ sed --version
GNU sed version 4.1.5

% uname -a
Linux hostname 2.6.24-xxxxxxxx-generic #1 SMP Tue Mar 30 18:11:30 UTC 2010 x86_64 GNU/Linux

환경에서 테스트했습니다.