http://www.perlmonks.org?node_id=1016380


in reply to Re^2: RFC - File::Util 4.x Series Pre-Release
in thread RFC - File::Util 4.x Series Pre-Release

Why 5.6 or even older versions? Are you supporting legacy systems? Unicode support seems far more important these days.

Elda Taluta; Sarks Sark; Ark Arks
My deviantART gallery

Replies are listed 'Best First'.
Re^4: RFC - File::Util 4.x Series Pre-Release
by Tommy (Chaplain) on Jan 31, 2013 at 21:06 UTC

    Well. I'm getting a big indication that Unicode is a priority, moreso than back compat. This has got my head buzzing with ideas... such as detecting old Perls and conditionally enabling Unicode if the Perl is new enough. I just don't know if it can be done at runtime -- haven't tried it yet. Seems like an unwise strategy.

    I may just throw down the guantlet and support Unicode, requiring 5.8 from now on... after all, that's what Perl did. If you don't like it, you can always go get an older version, right?

    Tommy
    A mistake can be valuable or costly, depending on how faithfully you pursue correction

      Be warned, that is a big ask and a very big task to do portably.

      Perl really doesn't have any built-in facilities to deal with Unicode paths on Windows.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        I appreciate the words of wisdom, especially from someone so steeped in the dark arts of Win Perl ;~)

        Getting down to business though, I think it would just be a matter of blacklisting filenames (not paths) containing things that qualify as a "path root" or a path "separator". After that, what's to stop me from letting the user (try) to push anything into the interface that they want? After all, if it can't be done, Perl itself will be the one to throw the error at the end of the call stack. I'll just kindly return the error... such is my thinking.

        Normalization / canonicalization are totally different matters. I'm not sure I even want to attempt that. I'd have first believe it was a useful "feature". Then again, maybe it's been done before and I could use what's already been written. Haven't checked CPAN for that yet.

        Bottom line, I think it's doable in the sense that other than the basic aforementioned checks, I would just step back and let Perl make the final decisions on what it will and won't accept, instead of the hand holding and "protections" I currently have in place.

        Backing off a bit from the nanny mentality is something I've been considering for some time.

        It's terribly late, and I'm rambling. But thanks BrowserUK, you always get me thinking outside the box.

        Tommy
        A mistake can be valuable or costly, depending on how faithfully you pursue correction