On Wed, Nov 9, 2011 at 6:20 PM, Peter Brett
<address@hidden> wrote:
Nala Ginrut <
address@hidden> writes:
> But Guile will break in (command-line) proc, because Chinese string as
> command arguments can not get valid result from
> "u32_conv_from_encoding" called by "scm_from_stringn", and raised an
> error.
should use the environment-provided locale by taking the following
steps:
1) Save current locale.
2) Set locale from environment.
3) Call scm_*_locale_string() functions.
4) Restore original locale.
However, note that this still may cause decoding errors, because there's
no guarantee that argv is in the same encoding as the environment
specifies, or indeed in any valid encoding at all. So consider *also*
adding e.g. a (command-line-bv) function to return the command line
without attempting to decode it.
This couldn't be the final solution.
Even we add a (command-line-bv), it may cause encoding-error. Because (command-line) would read argv too , and raise the error.
Unless we use (command-line-bv) and delete (command-line).
> So we don't have any chance to convert it or change locale from
> environment in the users' code because Guile has already crashed by
> "decoding-error".
Hang on -- are you saying that if you run Guile with badly-encoded argv
then it will die before running any user code? That would obviously be a bug.
I think so. I mentioned it in the first mail of this thread.
The badly-encoded argv can not get valid result but NULL from "u32_conv_from_encoding". So scm_from_locale_stringn will raise encording-error directly and show the argv as bytevector.
But even none-badly-encoded argv can not get valid result either. I checked out the code, current_charset() can not return the correct current locale. I must run setlocale(LC_ALL,"") to query locale from environment first.
But I think what you mean is *not query locale from envrionment*.
If this is not a bug. And locale string can not get result from environment locale. The solution maybe get rid of (command-line), use (command-line-bv), it's the easiest way. But I don't think it's the best way.