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>