Re: LSR - file information [0.24759]

[David Wright]

On Sun 27 Nov 2016 at 22:51:15 (+0100), Thomas Morley wrote:
> 2016-11-27 19:48 GMT+01:00 Trevor Daniels <address@hidden>:
> >
> > David Kastrup wrote Sunday, November 27, 2016 5:14 PM
> >
> >> File names are a tricky area in itself.  I think that there is some
> >> normalization process involved in some systems that tries to make sure
> >> that something like an ä will be recognized regardless of whether it is
> >> written as a single character with umlaut or a combining diacritic with
> >> letter a.
> >>
> >> I am not sure, but I think Linux does not even try at least on its
> >> native file systems.  No idea how this would work with Windows.
> >
> > I successfully saved your email with a name of éèö.eml in Windows
> > Vista, so I presume all later versions of Windows will be happy with
> > UTF8 file names.
> >
> > Even using  "filename_名字.eml" works fine, at least for Windows
> > native applications like Windows Mail.
> >
> > Trevor
> 
> The issue is not to store UTF8 file-names, but to access them with guile
> 
> Here another grrrrrrrrrrrrr:
> 
> /home/hermann/lilypondH/Test/forum/chin
> contains the above mentioned filename_名字.scm, nothing else.
> 
> In a .ly-file I have:
> 
> #(define dir (opendir "/home/hermann/lilypondH/Test/forum/chin"))
> #(do ((entry (readdir dir) (readdir dir)))
>     ((eof-object? entry))
>   (if (eq? (stat:type (stat entry)) 'regular)
>       (begin
>         (format #t "\nguile found this file: ~a\n\n" entry)
>         (system (format #f "guile ~a" entry))))
>   (newline))
> #(closedir dir)
> 
> Compiling it with LilyPond 2.19.52-guile2 results in
> 
> lilypond-git atest-47.ly
> GNU LilyPond 2.19.52
> Processing `atest-47.ly'
> Parsing...
> 
> 
> guile found this file: filename_名字.scm
> 
> ;;; Stat of /home/hermann/lilypondH/Test/forum/filename_??.scm failed:
> ;;; ERROR: In procedure stat: No such file or directory:
> "/home/hermann/lilypondH/Test/forum/filename_\u540d\u5b57.scm"
> Backtrace:
> <snipping the rest, same as above>
> 
> I mean, seriously???
> Found and _not_ found???

Why isn't "chin" in the output?

Cheers,
David.