Tanktalus has asked for the wisdom of the Perl Monks concerning the following question:

Ok, this is a bit odd ... it took me a few hours to figure out why this didn't work: 

my $s = do {
  # don't care about warnings.
  local *STDERR;
  open STDERR, '>', File::Spec->devnull();
  code_that_warns_deep_in_core_perl(); # and I can't figure out why
};

[download]
The warning still showed. Yet if I ran the script as perl ./x.pl 2> /dev/null, well, it didn't show up. So no one is reopening anything, as my first guess supposed... and then I realised that it wasn't the warning (since a small test script didn't exhibit the same problem), but that I use diagnostics. It's only the diagnostics that show up. Ugh.

So, first question: does anyone else consider it a bug that the above doesn't DWIM when using diagnostics?

Second question is ... has anyone had any problems with codepage conversions causing: 

Use of uninitialized value in lc at /usr/lib/perl5/5.8.7/utf8_heavy.pl
 line 123.

[download]
(That's the line that says: 
if (my $base = ($utf8::Canonical{$canonical} || $utf8::Canonical{ lc $
+utf8::PropertyAlias{$canonical} })) {

[download]
) I haven't been able to pare it down, unfortunately, to a smaller working example. The idea is that I'm reading some XML files (XML::Twig), getting the text from there, and then doing some funkiness with the text to modify it based on data I get from elsewhere. I split the text using a reasonably complex regexp (for a split, anyway), and then I uc some of it. This, apparently, causes perl to go into utf8_heavy's utf8::SWASHNEW method where it tries to lc something that I don't get.

I've even tried to use Encode::decode to decode the UTF-8 from the XML file, but no change in behaviour (that I've noticed) there. Any clues would be appreciated. Meanwhile, I'm going to continue trying to pare down to a minimal-working example that gets the same error.

Replies are listed 'Best First'.
Re: diagnostics, STDERR, and codepage conversions (TFM)
by tye (Sage) on Aug 13, 2007 at 17:14 UTC

    Don't use typeglobs to save, copy, or restore file handles; they suck for that. Use open and the examples documented there for how to save, redirect, then restore a file handle.

    - tye        

[reply]

      Ok, I've been pouring over this trying to figure out what you're referring to. Reading my local docs on open, I don't see any open examples that don't use typeglobs (well, one uses a lexical, the rest use typeglobs). Further, I'm redirecting STDERR - a typeglob. I am not introducing new typeglobs (other than a localised version of STDERR), and am attempting to keep anyone from using that global. So I'm not sure how it's relevant to cleaning up the hack anyway - I'm trying to modify a built-in typeglob, so I think I pretty much have to use that typeglob.

      Second, I'm not sure how your help is related to the questions I actually had. I suspect that you didn't intend to answer those, but unless I can be sure about your intentions, I have to assume you may have had a gem in there that I'm currently unable to grasp that would help my codepage conversions (whose code I didn't show, I conceded I couldn't boil it down yet, and doesn't use typeglobs at all).

      So I'm a bit confused. Any clarification would be helpful.

[reply]

        open gives examples of how to save, redirect, and restore file handles. That example does not do things the way you did. Yes, doing it the wrong way is why your code isn't redirecting correctly. Yes, that was the question you asked that I was addressing. No, I had no comment on your second question.

        The open examples (implicitly) pass typeglobs as arguments to open(). They don't use any typeglob syntax, not a single use of * except in some example regular expressions). They don't manipulate typeglobs directly in hopes of having a similar impact on the file handles contained in them.

        Rephrased more clearly and more correctly: Don't copy, save, or restore typeglobs that contain open file handles.

        And, of course, when the standard documentation shows how to do something, it is often a good idea to pay attention.

        I am not introducing new typeglobs (other than a localised version of STDERR)

        Yep, you even figured out which one I'm talking about, but refused to belive it? :)

        If it was a good idea to save/restore a file handle with a simple local(*STDERR), do you think the example of how to save/restore a file handle in the standard open docs would have avoided such?

        - tye        

[reply]
[d/l]
[select]

Back to Seekers of Perl Wisdom