On Wed, Nov 9, 2011 at 9:45 PM, Peter Brett <pe...@peter-b.co.uk> wrote:
> 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. > > 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...
