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.