Subject: Re: lib/13: getopt(3) should handle wide characters intelligently
To: None <firstname.lastname@example.org>
From: YAMAMOTO Takashi <email@example.com>
Date: 10/14/2001 09:16:41
[move to tech-userlevel from tech-toolchain]
From: "Jarom=EDr" Dolecek <firstname.lastname@example.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).
are you talking about 'n' of "echo -n abc" ?
if so, supporting only portable character set seems
"abc" of "echo -n abc" should be multibyte-capable, IMO.