Nala Ginrut <nalagin...@gmail.com> writes:
> 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).
(command-line-bv) should never cause an "encoding-error", because it
should never try to decode the command line.
Users of (command-line) should catch a potential "encoding-error" and
handle it appropriately.
> 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.
Well, you still need to provide (command-line) and (program-arguments)
functions compatible with existing code. I think the root of the
problem is that Guile calls scm_set_program_arguments() [feature.c:72]
early in initialisation, and this can fail messily.
I still think your proposed "solution" causes WAY more problems than it
claims to solve, though. What do Andy & Ludovic think?
Peter
--
Peter Brett <pe...@peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre
