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