Subject: Re: a proposal for two new libc functions: shquote() and shquotev()
To: Chris G. Demetriou <cgd@netbsd.org>
From: Jun-ichiro itojun Hagino <itojun@iijlab.net>
List: tech-userlevel
Date: 03/04/2001 13:33:12
>> 	there are localized shells, which allows Japanese text input on command
>> 	line for example (see freebsd ports/japanese/tcsh).
>Are there /bin/sh-equivalents?
(quote order changes)
>how does /bin/sh cope with use of variable values and/or arguments
>that are in non-ASCII strings?  Certainly, I don't see mention of
>'setlocale' or multibyte chars in /bin/sh?

	not sure, i guess there shoulde be japanized bash.
	for /bin/sh, if there's no setlocale() call, it will be C locale only.

>This is kind-of an interesting issue: are envionment variable values
>for things like this, command names, etc., going to be in
>e.g. Japanese?

	there are people using Japanese string for filenames.  also,
	think about it:
	$ grep 'sushi' /tmp/foo
	how do you put "sushi" in Japanese letters here?

>I think this probably says to me that either:
>
>(1) the tools that use this are meant for C locale, or
>
>(2) despite the additional difficulties, splitting is better than
>    quoting, if you can reasonably demand that the values of the
>    relevant environment variables (used for command names w/ possible
>    options) be in ASCII, or
>

>(3) you've gotta bite the bullet and do this multibyte...
>
>If (3), splitting probably better than quote-and-hand-to-/bin/sh,
>because /bin/sh isn't multibyte-char aware!
>
>Thoughts?

	i vote for (3).  if you use mbrtowc() in shquote(), like printf() is
	using it,
	- if you are using C locale it works just like now
	- if you use some other locale setting, it wlil be supported
		but for /bin/sh, it won't be the case until we have setlocale()
		call in /bin/sh)

itojun