Neville,
The htaccess solution would also not harm other apps because the environment
variable is only set when executing .lc files and they’re only used within that
session.
Von meinem iPhone gesendet
> Am 18.08.2023 um 03:07 schrieb Neville Smythe via use-livecode
> :
>
> Hi Matthias, I
Hi Matthias, I didn’t see your post until now. I did wonder if .htaccess could
be used using Rewrite rules, but I couldn’t get my head around the
documentation.
So it’s good to know both methods work. We are running other apps on the
website so I wonder a bit if setting the environment
Hi Neville,
did you read my comment about setting the environment variable lang using
.htaccess?
That worked here and i could write non-ascii filenames using the "standard" LC
Server installation.
Regards,
Matthias
> Am 17.08.2023 um 15:56 schrieb Neville Smythe via use-livecode
> :
>
>
Thank you Mark, installing the launcher script to set environment variables has
fixed all my issues with non-ascii filenames. The documentation for installing
LCS could usefully make a note of these settings. And indeed TextEncode/Decode
both work as expected, my musings there were irrelevant.
It seems it is possible to set environment vars using redirect rules in
.htaccess.
I added the following lines to my .htaccess
RewriteEngine on
RewriteRule \.(lc) - [E=LANG:de_DE.UTF-8]
the 2nd line or better tells Apache not to redirect, but to 'use' the flag
[E=] when an .lc file is
Hah! This reminds me of a time when Windows would allow files with names that
were legal for Mac to be written to its own file system who’s filenames were
NOT legal. The result is you could save the files, but you could never access
or delete them, neither could you delete any folder that
On 2023-08-16 06:37, Neville Smythe via use-livecode wrote:
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
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
>
On 2023-08-15 08:42, Neville Smythe via use-livecode wrote:
So if I understand Mark correctly, while one can create utf-8 encoded
filenames directly in a terminal
session, LC Server internally accesses Apache environment variables to
encode/decode the filename
before opening a file rather than
What definitely works, at least here, is to urlencode the filename before
creating it
So that e.g. testä would be created as test%E4
As urlencode does not "harm" you could use it in general, not only for
non-ascii file names.
And if you want to display the "real" name you just have to
Thanks Mark and Matthias
I think it is clear the problem is not related to variant forms - if I replace
[e-acute] by any other non-ascii character, such as a Kanji character or emoji,
I get the same “can’t open that file” error. And the weird decoding of
[e-acute] to [E-grave] would be
see below...
> Am 14.08.2023 um 13:30 schrieb Mark Waddingham via use-livecode
> :
>
> On 2023-08-14 12:12, matthias rebbe via use-livecode wrote:
>> Hi Mark,
>> when i read Neville's post i thought also about normalize, although i really
>> do not have a clue about the whole unicode stuff,
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
On 2023-08-14 12:12, matthias rebbe via use-livecode wrote:
Hi Mark,
when i read Neville's post i thought also about normalize, although i
really do not have a clue about the whole unicode stuff, but i
remembered that the standalone builder make use of the normalize
function. ;)
So i used
Hi Mark,
when i read Neville's post i thought also about normalize, although i really do
not have a clue about the whole unicode stuff, but i remembered that the
standalone builder make use of the normalize function. ;)
So i used this script on LC Server to write the seconds to a file
On 2023-08-14 02:45, Neville Smythe via use-livecode wrote:
OK, so the macOS *is* using utf-8 for its file names - the [e-acute] in
the filename Carré.txt is rendered with two bytes [C3A9] not the single
byte MacRoman encoding. I got tricked by copying the terminal listing
into another program
OK, so the macOS *is* using utf-8 for its file names - the [e-acute] in the
filename Carré.txt is rendered with two bytes [C3A9] not the single byte
MacRoman encoding. I got tricked by copying the terminal listing into another
program rather than hex dumping within the terminal, and somewhere
17 matches
Mail list logo
