Linux filenames in LC Server

[Neville Smythe]

Thanks Mark for semi-unfuddling me. It’s good to know that textEncode/Decode is not to blame.

But if I may try everyones' patience a little further

> In the case of Linux what encoding such 'sys strings' need to use 
> depends on the environment - the encoding *could* be anything and thus 
> the engine uses the UNIX 'iconv' library to convert from internal 
> representation to the encoded bytes needed. I think this is what is 
> causing the failure of the file APIs - iconv is refusing to convert a 
> string with non-ascii characters to the 'default' 'C' locale as it can't 
> (there is no mapping from, say, e-acute to ascii).

So I misunderstood, I thought we were talking about Apache environment variables. Indeed the Terminal app reports

LANG=C

as a system env variable. But if this is not specifically a server problem, wouldn’t that mean we could see the same behaviour with LC Desktop on Linux machines running vanilla Ubuntu or Debian (which is what Dreamhost uses)? I haven’t tried this yet, as it is a bit of pain to fire up my Linux emulator machine.

An experiment, which make me wonder if this counts as a configuration problem or an actual bug in LC Server:

 In Terminal I type (actually paste) and execute

 echo “éü😃” > Carré.txt 

    (for Forum users like me who just see ? everywhere, that is [e-acute][u-umlaut][happyface emoji] in the content to be written to a file with [e-acute] in its name)

   This works without problem. The contents of the file are utf-8 encoded, which I didn’t need to specify, but I guess that is what the pasteboard provided. Terminal had no problem creating or finding the file without needing those env settings. Of course it cannot *display* the file name without knowing the encoding, so ls reports the filename as 'Carr'$'\303\251''.txt’ ( readable as an ascii encoding, though not one I have seen before; note the single quotes)

     If I setup the env variables Mark suggests in the Terminal session

export LC_ALL="en_US.UTF8"
export LANG=“en_US.UTF8”

then Terminal is able to display the filename á la française.

      Cyberduck reports this filename correctly using the [e-acute] without having to set encoding knowledge. And I can also create the file using Cyberduck with no problems. So IT knows about/expects/sets up the encoding as needed. I bet other Linux-aware apps would also open or list such files without drama or special configuration.

   However: in LC Server when I call "the long files" for the enclosing folder: crash! (Actually an in-line error reported for this code line). To my mind that qualifies as a bug, even if the source of the crash is the same as for open file.

   On the other hand hopefully setting the environment variables as Mark suggests will fix everything . Mark, could I clarify exactly how that “launcher script” is to be used… I’m guessing the cgi configuration should point to that file to be executed when it wants to open myscript.lc instead of pointing to the livecode-server executable (in which case it might have to have a .cgi suffix rather than .txt), or is it a shell script to be executed by livecode-server?

Neville Smythe