Subject: Re: lib/13: getopt(3) should handle wide characters intelligently
To: None <jdolecek@netbsd.org>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: tech-userlevel
Date: 10/14/2001 09:16:41
hi.
[move to tech-userlevel from tech-toolchain]

From: "Jarom=EDr" Dolecek <jdolecek@netbsd.org>
> I have not found that the referred to 'Guideline 3' contains,
> but I expect it to contain US-ASCII characters only.

guideline 3 is:
>    Guideline  3:
>        Each option name should be a single alphanumeric character (th=
e alnum character
>        classification) from the portable character set.
>        Multi-digit options are not allowed. Instances of historical u=
tilities that used them
>        have been marked LEGACY in the XCU specification, with the num=
bers being changed from
>        option names to option-arguments.



> So, it's perfectly reasonable for getopt(3) to not support wide
> characters and an application using them would not be portable anyway=
.=

> Given this (and bloat factor mentioned above), I don't really
> see compelling reason to add that support to getopt(3).
> =

> Thoughts?

are you talking about 'n' of "echo -n abc" ?
if so, supporting only portable character set seems
reasonable.

"abc" of "echo -n abc" should be multibyte-capable, IMO.

---
YAMAMOTO Takashi<yamt@mwd.biglobe.ne.jp>