On Wed, Nov 9, 2011 at 9:45 PM, Peter Brett
<address@hidden> wrote:
Nala Ginrut <
address@hidden> 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.
Well, one of the approaches could be "call command-line-bv after encoding-error rased".
We can put command-line-bv in the error handler of encoding-error.
Argv will be bytevector if encoding error occurs.
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.
Hmm...I mentioned *deal with argv too early* in IRC with Andy.
But I chosen an easier way to fix this problem with query locale from environment.
Now it seems to be improper...