Subject: Re: finger
To: None <joda@pdc.kth.se>
From: T.SHIOZAKI <tshiozak@astec.co.jp>
List: tech-userlevel
Date: 09/12/2002 15:34:34
From: joda@pdc.kth.se (Johan Danielsson)
Subject: Re: finger
Date: 11 Sep 2002 23:57:35 +0200
Message-ID: <xofu1kwdwa8.fsf@blubb.pdc.kth.se>
> > Our finger is quite old program. Although good-old-day's libc was
> > hard-coded to ASCII, the recent (ISO C compliant) libc is no longer
> > so.
>
> Yes, but what does this have to do with finger using isprint? What
> stops you from doing something with fgetwc/iswprint/fputwc?
I do not necessarily oppose to use wchar_t in finger *client*.
I guess this is a matter of degree.
I considered:
1. It is difficult to realize i18n of finger perfectly
within the scope of rfc1288, because of thoughtless about
i18n, e.g. it lacks the codeset negotiation, etc...
2. rfc1288-complient fingerd cannot use wchar_t because
wchar_t should be used as opaque, but rfc1288 requires
fingerd to touch character codes transparently.
3. Our fingerd implementation just forwards the outputs of
finger. If we use wchar_t family functions in finger recklessly,
this finger conflicts with 2.
4. For instance, we can add some #ifdef into src/usr.bin/finger/*
and separate executables into /usr/bin/finger and /usr/libexec/finger.
Here, the former is the internationalized version by using wchar_t
and the latter is the raw octet version for fingerd.
Otherwise, we can add some option whether it uses wchar_t.
5. remember 1. We cannot realize i18n of the finger system perfectly
even if 4 is done. I wonder whether we should do so.
In such case, I prefer to make it moderate rather than
touch it to excess.
--
Takuya SHIOZAKI / ASTEC Products, Inc.