Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us> writes:
> The point of shquote() (i.e., the "contract" with the programmer using
> it) is to match the conventions of the shell used by popen() and
> system(); if we get a multibyte-aware /bin/sh, shquote will need to be
> multibyte aware.  A shquote() portable among systems with and without
> multibyte-aware shells will need to behave in a way which matches the
> system its running on.

But, it's slightly worse than that:

the args to a program are often going to be interpreted by a user's
shell.

if the program splits environment variables and does execve, then it
can run on a system supporting multibyte user shells w/o a multibyte
/bin/sh, since the args won't get reinterpreted by /bin/sh

if the program does quoting+shell, then /bin/sh has to be safe for
multibyte chars to guarantee correct operation.


I think the 'right' solution is "have a multibyte-safe /bin/sh, and do
multibyte stuff in the library."

Without the multibyte /bin/sh (or maybe even with it if you're willing
to limit your args to ASCII), sure you don't want to do the multibyte
char thing...  but that can severely impact the user experience with
programs that use this interface, for multibyte char users.


I'm thinking that i'll code the multibyte code, and #ifdef it with a
compile-time option... but really i won't be able to verify that it
works...


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.