Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2014-12

file name encoding

5 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marc Santhoff

Hi,

hopefully this is not too far OT i dare to ask:

When reading directories and files using FindFirst()/FindNext() using system encoding my program hangs on german '?' (eszett).

I'm using fpc 2.6.2 and lazarus 1.2.0, so string encoding should normally be the same as the system encoding. On the console nothing is wrong, but in an xterm it fails.

The encoding difference between consol and xterm is only:

XTERM_LOCALE=de_DE.ISO8859-15

and the termcap var belonging to it.

OS is FreeBSD 9.1-STABLE amd64

Complete locale settings:

console:
LC_CTYPE=de_DE.ISO8859-15
LC_COLLATE=de_DE.ISO8859-15
LC_TIME=de_DE.ISO8859-15
LC_NUMERIC=en_US.ISO8859-1
LC_MONETARY=de_DE.ISO8859-15
LC_MESSAGES=en_US.ISO8859-1

xterm:
TERMCAP=xterm|X11 terminal emulator:...
XTERM_LOCALE=de_DE.ISO8859-15
LC_MESSAGES=en_US.ISO8859-1
LC_CTYPE=de_DE.ISO8859-15
LC_TIME=de_DE.ISO8859-15
LC_COLLATE=de_DE.ISO8859-15
LC_NUMERIC=en_US.ISO8859-1
LC_MONETARY=de_DE.ISO8859-15

What is the exact problem here and how can it be solved?

Marc Santhoff

Reply by email

Marco van de Voort
to Marc Santhoff: hopefully this is not too far OT i dare to ask: When reading directories and files using…
Marc Santhoff wrote 8 lines
hopefully this is not too far OT i dare to ask: When reading directories and files using FindFirst()/FindNext() using system encoding my program hangs on german '?' (eszett). I'm using fpc 2.6.2 and lazarus 1.2.0, so string encoding should normally be the same as the system encoding. On the console nothing is wrong, but in an xterm it fails.

I can't imagine why it would go wrong, findfirst/findnext in 2.6.x are afaik binary, without encoding conversion.

Did you try to strace it ?

Reply by email

Marc Santhoff
to Marco van de Voort
Marco van de Voort wrote 14 lines
On Sun, Dec 14, 2014 at 05:21:15PM +0100, Marc Santhoff wrote: > hopefully this is not too far OT i dare to ask: > > When reading directories and files using FindFirst()/FindNext() using > system encoding my program hangs on german '?' (eszett). > > I'm using fpc 2.6.2 and lazarus 1.2.0, so string encoding should > normally be the same as the system encoding. On the console nothing is > wrong, but in an xterm it fails. I can't imagine why it would go wrong, findfirst/findnext in 2.6.x are afaik binary, without encoding conversion. Did you try to strace it ?

No, not yet. I wanted to avoid hours of strace or debugging sessions with the chance of making a very dump known error. While waiting I kicked out some other bugs in my code and today ... it can't be reproduced.

When the error has been occuring it reproducably failed hanging in the xterm on the char '?', verified by renaming the first file with that char in the name and seeing the program hang on the second one. I had to use CTRL-c to stop it. Other german chars, 'umlauts', where working fine although being written to the xterm using a wrong char set.

The bugs fixed afterwards have no relation to encoding. One of them was handing the wrong container to a deeper recursion level, but there are no dangerous pointer handlings or similar involved. Only plain type checked class instances, none of them got lost, only the wrong one was filled with data. I have no idea what happened.

Sorry for the noise and thank you!

Marc Santhoff

Reply by email

Marc Santhoff
to Bart: Did you try FindFirstUtf8/FindNextUtf8? Bart
Bart wrote 6 lines
On 12/14/14, Marc Santhoff wrote: > When reading directories and files using FindFirst()/FindNext() using > system encoding my program hangs on german '?' (eszett). Did you try FindFirstUtf8/FindNextUtf8?

No, I didn't. I thought about using SysToUTF8 when reading, but when I'm sure the system file names are not encoded UTF-8 that would have been rather senseless. It don't know exactly, but any non ascii char would have been encoded wrongly, wouldn't it?

I'll check that out of curiosity ... ;)

Thanks.

Marc Santhoff

Reply by email