This has been fixed. When I retrieved the $working_directory from the filechooser button, it was returning an encoding other than utf-8. I fixed the problem by doing... 
   $working_directory = encode('UTF-8', $working_directory);

[download]
The only thing I can figure is that File::Find uses whatever encoding you pass to it upon initializing with the top-level directory and uses that encoding for the rest of its recursion. If that is the case, it is a bug as it should use whatever perl does which is by default utf-8. Can someone verify this? Original message starts now.......................... Hello Monks, I wrote a command line perl script which traverses a directory tree and recursively works on the files contained within. This script works perfectly. I then decided to use gladexml to incorporate a gui in my application. Now it doesn't work so good. I am using seperate modules and exporting/importing the variables as needed using EXPORT_OK. The portion of the program I am having problems with is... 
   find (\&wanted, $working_directory);
    sub wanted
    {
        $filename = $_;
        $working_file = $File::Find::name;
        if (-d $File::Find::name)
        {
        $filetype = "directory";
        }
     ......
    else
        {
        print LOGFILE "ERROR: $working_file does not exist!!! ABORTING
+!!!\n";
        exit 1;
        }

[download]
When I define $working_directory='some_directory' it works fine from the gui or command line version. However, when I import the variable from the other module (even though it prints out as being equivalent) in the using module, a directory that contains an accented character (like a 'u' with the two dots over it or an 'e' with the forward tick above it) File::Find can not find it and my dir handler kicks in and the program exits. That isn't the strangest part. I write to a log file any errors encountered. This is what I get when I view the logfile manually using kwrite with the default encoding utf-8... gris_foncé does not exist!!! ABORTING!!! This is what I get when I use the built-in log viewer using a Gtk2::Textview in the same program... gris_foncĂ© does not exist!!! ABORTING!!! Now when I change my encoding to iso8859-15 in kwrite, I get... gris_foncĂ© does not exist!!! ABORTING!!! I have tried 
   use utf8;

[download]
to no avail. It makes no sense as to why this is occuring as my Ubuntu Feisty and Gutsy systems have utf8 encoding by default. I can't see it being Glade either as my glade file starts with... 
   <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <!DOCTYPE glade-interface SYSTEM "glade-2.0.dtd">
   <!--Generated with glade3 3.4.0 on Sat Nov  3 19:55:02 2007 -->

[download]
Is this a glade problem or a perl problem. I hope someone has an answer. Thank you.

In reply to File::Find and character encoding problem (fixed) by smitty7523

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.