On 2023-08-14 12:30, Mark Waddingham via use-livecode wrote:
So assuming that the defaultFolder is accessible in your above script
(as a read-only folder would also cause the same error) then there does
appear to be something up here...
Okay so I'm pretty sure the linux server engine is doing the right
thing.
As mentioned previously, Linux filesystems don't actually care what the
encoding of a filename is - to linux its just a sequence of bytes
The interpretation is given by the 'locale' settings which are in effect
for any given program.
So, when you run lc-server from a terminal session directly, its almost
certainly the case that the LC_ALL and LANG environment variables are
set to en_US.UTF-8 (or some other language code DOT UTF-8 - it is the
UTF-8 which is the important bit).
On Linux, a C API nl_langinfo() is used to fetch the encoding to use
when talking to the system APIs (e.g. filesystem APIs) - this (I
believe) derives its information from LANG/LC_ALL.
If the latter *are not set* then it will likely default to the 'C'
locale which has no interpretation of any non-ascii chars, and thus
attempts to encode/decode utf-8 encoded filenames will fail.
My theory is that these variables are not set in the configuration for
running CGIs in Apache (or whatever web server is being used in this
instance).
Digging around it looks like Apache (at least) has a `SetEnv` directive
which would allow these environment variables to be set, e.g.
SetEnv LC_ALL en_US.UTF-8
SetEnv LANG en_US.UTF-8
Although I'm not 100% sure where such things go, perhaps someone more
conversant with apache config could chime in to suggest.
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Build Amazing Things
_______________________________________________
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
