꽃삽질 : fcitx 와 zsh. 문제의 시작과 끝.

남들이 가지 않는 길을 가려고 한다면, 이런 일은 각오를 해야만 하는데도 불구하고, 아직도 익숙해지질 않는다. 아아아..

zsh 를 설치하고, chsh 명령을 사용하여 기본으로 만들었다. 그동안은 nimf 를 사용했기 때문에, 지금부터 적어내려갈 문제를 인지하지 못하고 있었다.
문제는 다음과 같다.

zsh 가 기본값(Default Shell)일 경우, fcitx 가 제대로 작동하지 않을 가능성이 있다.

이 문제는 im-config 와 밀접한 연관이 있다.
이 사실을 알아내기까지, 꽤 많은 시간이 걸렸고, 해법을 찾다가 짜증이 난 나는, 결국 콜라를 한병 까고(?) 말았다.

---

문제의 발단은 Anki 였다. 내 보고가 그래도 조금은 역할을 했으려나? 새로운 베타판이 나왔다는 글을 읽고, 받아서 설치를 해봤다. 그 당시에는 Nimf 를 사용 중이었으니, 입력기를 fcitx 로 바꿔줬다.

그런데.. 이게 나를 꽃삽질로 이끌고 말았다.

im-config -n fcitx

그리고 재부팅하여 돌아왔는데, 먼저 입력창이 눈에 거슬렸다.

그림이 잘 보이진 않지만, 한글을 입력할 때, 커서가 있는 위치에서 문자가 조합되지 않고, 입력창이 따로 열렸다. 처음엔 fcitx 설정 문제라 생각하고, fcitx 만 샅샅히 훑었었다.
그러나 결국 실패. 어느 설정을 건드려도 이 문제를 바로 잡을 수는 없었다.
다음 순서는 역시나 구글의 길로. 같은 문제로 도움을 요청한 글은 쉽게 찾았지만, 답은 역시나 찾질 못했다.

그러다가.. 혹시나 Nimf 때문인가 하여 Nimf 를 지워보기도 했고, VBox 에 새판을 설치하고 이런 저런 시험을 해보기도 했다.

그런데, 입력창이 이상한 문제만이 아니었다. QT 프로그램, 즉 KDE 에서는 아예 한/영 전환이 되질 않았다. 이건 환경변수가 제대로 설정되지 않았을 때 나타나는 현상인데?

$ export | grep fcitx
XMODIFIERS='@im=fcitx'

어라.. 이건 문제가 있다. 제대로 되려면 이렇게 나와야 한다.

$ export | grep fcitx
GTK_IM_MODULE=fcitx
QT4_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS='@im=fcitx'

GTK, QT 등이 안보인다. 이거 도대체 왜 이런거냐..

---

이게 zsh 와 관련이 있을 거라는 생각은 언제, 어떻게 했더라? 계기는 기억이 나질 않는다. 아마도, export 의 결과가 좀 다르게 나온게 역시나 내 비위(?)를 거슬렸을 지도 모르겠다.
bash 라면 아래와 같은 결과가 나와야 한다.

$ export | grep fcitx
declare -x GTK_IM_MODULE="fcitx"
declare -x QT4_IM_MODULE="fcitx"
declare -x QT_IM_MODULE="fcitx"
declare -x XMODIFIERS="@im=fcitx"

declare -x 가 있고 없고의 차이는 export 가 되어 하위 Shell 에까지 영향을 미칠 수 있느냐, 즉, 환경변수화 하느냐 마느냐의 차이다.

zsh 와 연관이 있다는 건 알았으니, 이젠 그 부분으로 파보면 되는 일인데, 이제부턴 과연 저 환경변수가 어떻게 실행이 되는지 궁금해졌다.
어디에 기록이 되어 있을까? $HOME 에?

열심히 찾아봤지만, $HOME 에는 없었다.

해서, 일단 임의로 환경변수를 넣어보기로 했다. zsh 이므로, .zprofile, .zshenv, .zlogin 등등을 총 망라했다. 그러나 모두 실패. export GTK_IM_MODULE="fcitx" 항목 등등을 넣어줬지만, 재부팅을 해도 도무지 저 내용이 뜨질 않는다. 또, 저 항목을 넣고 나면 fcitx 가 실행도 되지 않는다. (아닌가? 되긴 됐었나? 이거 저거 했더니 잘 기억이 나지 않는다.)

그 다음은 또 다른 문서 참고해서 ~/.config/environment.d/*.conf에 환경변수를 넣어줬으나, 또 실패.

.xprofile 도 실패.

도대체 원인이 뭐야…???

…
그러다가, .xsession-errors 파일을 살펴보게 되었고, 거기에서 “no matches found: /usr/lib/gtk-2.0/*/immodules/im-fcitx.so” 이란 항목을 볼 수 있었다. (해결이 된 다음에 확인을 해본 결과, 저 오류는 발생한다해도 fcitx 동작에 영향을 미치지는 않는 듯 하다.)

그리하여, 이번엔 시스템 디렉토리에서 fcitx 를 찾아보기로 했다.
어떻게 찾았는지도 중요하다. 바로 얼마 전에 알아낸 grep 를 사용했다.

​$ grep -rwI /usr -e 'fcitx' 2> /dev/null
....
/usr/share/im-config/data/22_fcitx.rc:# start fcitx
...

레이더에 걸린 건 바로 /usr/share/im-config/data/22_fcitx.rc 였다.
이것을 기본으로, 구글에 zsh “/usr/share/im-config/data/22_fcitx.rc” 을 찾아보았다.

그리고 또 연결에 연결.. 뭔가 냄새가 나기 시작했다.

• Debian Bug report logs – #905129
• im-config: Wrongly run shell scripts with user’s shell interpreter, raises error with zsh
• Z-Shell breaks im-config configuration scripts, making input method malfunction
• Re:Z-Shell breaks im-config configuration scripts, making input method malfunction
• Use wrapper to search files instead of using shell glob expansion

여러 페이지가 있지만, 제일 첫 글의 마지막 부분에 답이 나와있다. im-config 0.36 판에서는 이 문제가 해결됐다고 한다.
zsh 는 for 문을 허용하지 않는데, 해당 스크립트에서는 for 가 사용되고 있어서, 오류가 발생했다고 한다. 따라서, for 를 사용하지 않게끔 수정했고, 그게 0.36 이다.
정확하게는 이렇게 쓰여있었다.

In file /usr/share/im-config/data/21_ibus.rc:

GTK_IM_MODULE=xim
# use immodule only when available for both GTK 2.0 and 3.0
IM_CONFIG_MARKER2=0
for IM_CONFIG_MARKER in /usr/lib/*/gtk-2.0/*/immodules/im-ibus.so \
                        /usr/lib/gtk-2.0/*/immodules/im-ibus.so ; do
    if [ -e $IM_CONFIG_MARKER ]; then
        IM_CONFIG_MARKER2=1
        break
    fi
done

Zsh does not accept the for statement, since on current unstable system
/usr/lib/gtk-2.0/*/immodules/im-ibus.so matches nothing. Zsh would fail here
while Bash and dash ignore the unmatched string.

Solution
=======

While the zsh-incompatible grammar can be fixed (perhaps with a thorough
examination of all im-config source code), the problem that
Xsession.d scripts are executed by user shell interpreter is a big problem
and should receive further examination.

그런데, zsh 가 for 를 아예 지원하지 않는 것은 아닌데, 자세한 내용은 봐도 모르겠으나, 저런 형식은 아무튼 안되는 모양이다.

쿠분투 18.04(KDE Neon) 에는 0.34 가 제공되고 있었다. 일단은 문제가 된 파일 2개만을 위 사이트에서 받아서 바꿔치기 했더니 fcitx 가 제대로 동작했다.
흠.. 이래도 괜찮긴 하지만, 혹시나 PPA 가 있나 해서 찾아보다가, 우분투 18.10 에는 0.38 이 제공되고 있다는 사실을 알 수 있었다. 하여.. 그냥 그 Deb 꾸러미를 받아 설치했다.

zsh 에서도 이제, 문제없이 fcitx 를 쓸 수 있다.
물론, Nimf 는 zsh 에 전혀 영향을 받질 않았다. 0.34 때나 0.38 때나. 그 이유는 다음에서 찾을 수 있다.

$ cat /usr/share/im-config/data/23_nimf.rc 
if [ "$IM_CONFIG_PHASE" = 2 ]; then
    nimf
fi

if [ "$IM_CONFIG_PHASE" = 1 ]; then
    XMODIFIERS="@im=nimf"
    GTK_IM_MODULE=nimf
    QT4_IM_MODULE=nimf
    QT_IM_MODULE=nimf
    CLUTTER_IM_MODULE=xim
fi

for 가 없다. 그래서 문제가 발생할 여지가 아예 없었다.

그런데, 한가지 이상한 점을 발견했다.
bash 와 zsh, 다음 결과가 다르다.

zsh$ export | grep IM
CLUTTER_IM_MODULE=xim
GTK_IM_MODULE=''
QT4_IM_MODULE=''
QT_IM_MODULE=''
XDG_RUNTIME_DIR=/run/user/1000

bash$ export | grep IM
declare -x CLUTTER_IM_MODULE="xim"
declare -x GTK_IM_MODULE="fcitx"
declare -x IM_CONFIG_PHASE="2"
declare -x QT4_IM_MODULE="fcitx"
declare -x QT_IM_MODULE="fcitx"
declare -x XDG_RUNTIME_DIR="/run/user/1000"

IM_CONFIG_PHASE 변수가 zsh 에는 나타나지 않는다. 왜 없을까?? /usr/share/im-config/data/22_fcitx.rc 에서도 이 변수값을 확인하는데, 여기서는 이 값이 제대로 존재함을 확인했다. (간단히 다음과 같이 touch 명령을 추가해서..)

if [ "$IM_CONFIG_PHASE" = 2 ]; then
    # start fcitx daemon
    # 확인용
    #touch $HOME/imtest/log_PH2_$(date +"%y%m%d-%H%M%S")
    /usr/bin/fcitx -d 2> /dev/null &
fi
....

왜 bash 와 zsh 가 다른지는… 이걸 알고 싶다면, 또 며칠을 투자해야할 지도 모른다.

---

정리 #1: fcitx 를 사용하면서, zsh 를 기본으로 쓰고 싶다면?

• 우분투 18.10 이상을 사용하든가,
• 그 이하 우분투를 사용하고 있다면, im-config 0.36 이상을 쓰라.

정리 #2 : 다국어 입력기(fcitx, ibus, nimf 등등)의 환경변수는 어떻게 지정이 되는가?

/usr/share/im-config/data/ 내의 .rc 파일이 실행되면서 시스템에 선언된다. $HOME 이나 기타 다른 위치에 ‘저장’되고, 그것을 읽어오는 형식이 아니다.

이걸로 끝이려나..
꽃삽질을 살짝 넘어서는 정도였다는 생각도 들지만, 그래도 이런 저런 잡지식이 늘어난데에 만족한다.