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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
