Re: g_filename_to_utf8 limitations on Win32

["J. Ali Harlow" <ali juiblex co uk>]

On 2004.10.29 04:26 Tor Lillqvist wrote:

> Hmm, true. We seem to need a g_argv_to_utf8() function?
>
> gchar **
> g_argv_to_utf8 (int argc,
> 		char **argv);		 

I suspect this will cause memory leaks unless you do some very fancy 
footwork. Owen's idea of using GOption looks to have the equivalent 
functionality without some of the caveats (eg., users calling 
g_argv_to_utf8 before option processing), but I don't know GOption well 
enough yet to be sure. Looks like I've got some reading up to do next week 
:-)

> (Of course, one cannot be 100% sure that command line parameters are
> in the supposed filename encoding on Unix. It's quite possible that
> one has LANG set to for instance en_US.UTF-8 but still uses an xterm
> and/or shell that actually generate ISO-8859-1 or whatever. Yes, this
> is a mess, and I usually tell my users to avoid non-ASCII chars in
> file names on Unix. We have a mix of Solaris 7, 8 and 9, and RHEL3
> (plus gazillons of Windowses of course). With just Solaris 9 and Linux
> UTF-8-everywhere would be possible, but on Solaris 7 and 8, it just
> isn't feasible. Throw in multi-protocol (NFS+CIFS) file servers that
> have their own quirks and want to know what encoding filenames coming
> in through NFS are in (per-NFS-client!, although locale settings are
> per-process...) and things can get hairy...)

Yes, I agree it's a mess. This is less of an issue to me since all my 
current users are on win32 and if we do ship a Unix system I can choose 
the version of Linux to ship that's best suited to the task. From glib's 
point of view, I think we just need to continue to ensure that 
G_BROKEN_FILENAMES will switch the encoding of filenames as command line 
arguments under Unix.

Cheers,

--
J. Ali Harlow
ali juiblex co uk