http://qs321.pair.com?node_id=1033062


in reply to Re^2: Problems with unicode properties in regular expressions under chroot (install)
in thread Problems with unicode properties in regular expressions under chroot

Ok, let's see here :) looking through my stuff I find expand unicode property (eg \p{Print}) to regex character class range so this seems to work

$ perl -Mutf8 -le " utf8->SWASHNEW(q/Print/) ; print for %INC"

A cleaner (no warnings) version seems to be

$ perl -le " qr{\P{Print}}; print for %INC; "

So you might grab perluniprops and qr// up a storm or File::Find and require up a storm

Anyway you look at it it's all kludges -- there needs to be an official API for this

preload_unicore (); print for keys %INC; sub preload_unicore { use File::Find::Rule; use Config(); my $privlib = $Config::Config{installprivlib}.'/'; my @files = File::Find::Rule->file->name(qr/\.pl$/)->in( $privlib. +'unicore/' ); tr{\\}{/} for $privlib, @files; s{^\Q$privlib\E}{} for @files; eval { require "$_"} for @files; }

Replies are listed 'Best First'.
Re^4: Problems with unicode properties in regular expressions under chroot (install)
by sgifford (Prior) on May 11, 2013 at 21:01 UTC
    Thanks! Actually, so far my quick hack is holding up pretty well, the program seems to be running without errors inside its chroot after a few days, so maybe my first take managed to track down all the properties that were needed.

    I thought that maybe the -C0 switch would turn off Unicode altogether, which would be OK for this particular script, but for some reason it still doesn't. In the debugger I tracked it down to some data from the network being encoded as ASCII with Encode, which for some reason set the utf8 flag.

    I also found a module Unicode::Tussle that had some ability to load up all entities, but really it doesn't seem any less kludgey than the ideas you provide above.

    Thanks again!

    -----ScottG.