Re: Non-ASCII characters in @include search path

[Gavin Smith]

On Sun, Feb 20, 2022 at 09:11:54AM +0000, Gavin Smith wrote:
> On Sat, Feb 19, 2022 at 11:00:33PM +0100, Patrice Dumas wrote:
> > I think that there is some wrong encoding/decoding somewhere,
> > but I don't know where.  It is particularly strange that I cannot
> > reproduce with 6.8 but Gaël can.
> 
> I reproduced with 6.8 but only with TEXINFO_XS=omit.  I am going to
> investigate.

I reproduced with the development version.  I found that the -f and -r
operators in Perl would not find a file named with an identical string
(showing equal with the eq operator) but encoded internally with UTF-8,
so that utf8::is_utf8 returns true.  The File::Spec functions return
such a string.  The following fixed it for me:

diff --git a/tp/Texinfo/Common.pm b/tp/Texinfo/Common.pm
index 29dbf3c8c3..8219534984 100644
--- a/tp/Texinfo/Common.pm
+++ b/tp/Texinfo/Common.pm
@@ -1548,6 +1548,9 @@ sub locate_include_file($$)
         File::Spec->catdir(File::Spec->splitdir($include_directories),
                            @directories), $filename);
       #$file = "$include_dir/$text" if (-e "$include_dir/$text" and -r 
"$include_dir/$text");
+
+      utf8::downgrade ($possible_file);
+
       $file = "$possible_file" if (-e "$possible_file" and -r 
"$possible_file");
       last if (defined($file));
     }


This is obviously a mess.  We should decide exactly where the bug is: in
the -e operator itself, in File::Spec, or in the way that we use it.

It might be simpler to eschew File::Spec and just get the filenames with
simple string operators.

$ perl --version

This is perl 5, version 30, subversion 0 (v5.30.0) built for 
x86_64-linux-gnu-thread-multi
(with 50 registered patches, see perl -V for more detail)

Copyright 1987-2019, Larry Wall