Subject: Re: a proposal for two new libc functions: shquote() and shquotev()
To: Chris G. Demetriou <email@example.com>
From: Jun-ichiro itojun Hagino <firstname.lastname@example.org>
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
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!
i vote for (3). if you use mbrtowc() in shquote(), like printf() is
- 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)