Re^2: no error messages for syntax errors?

...maybe a module you've starting using is redirecting STDERR to nul (/dev/null)?

I don't think that's it because if I remove the syntax errors so that the code works again, and then call

print STDERR "hello world.\n";

It prints exactly as expected. If stderr were redirected, then I wouldn't see that.

Besides, that shouldn't matter: if my code is redirecting STDERR, and there are syntax errors that causes the perl interpreter to terminate execution, that should write to my terminal regardless of where my code's perception of STDERR is, right? If not, you could really screw yourself up.

However, you raise an intereseting point: a possible source of confusion could be the CARP package, which has a BEGIN block and redirects STDERR for debugging cgi scripts (where there is no terminal to output to). I do include a module that has that, but as I said, this was never a problem before. Nothing's changed, unless there has been a reordering of use lines that include packages. Does order matter for stuff like that? Since I have this problem now, but didn't before, that might answer my own question. It might have been that the CARP package from some module was being masked.

I'll pre-empt someone's potential answer that might say, "don't do that" with a question: Can a module do that? (ie., a module use CARP to redirect stderr) Is it better/more appropriate/"blessed" to never have modules do that, and instead keep those in the main package?

Comment on Re^2: no error messages for syntax errors? Select or Download Code

Replies are listed 'Best First'.
Re^3: no error messages for syntax errors? by BrowserUk (Patriarch) on Dec 06, 2004 at 03:34 UTC
My two trains of thought were: Your shell's idea of where stdout was directed had changed because you were inheriting a shell alias, or environment variable that was explicitly redirecting stdout when you invoke your script. That `print STDOUT 'yada';` appears in the right place when the bug is not manifesting itself probably precludes this idea. Though, the perl debugger has a remote debugging option that might cause strange phenomena if it was being invoked silently? The other was that some module, like CGI::Carp that redirects STDERR to some other place (a log file or `fatalstobrowser` (I didn't receive any:)) and does it during the BEGIN{} phase, might be a possibility. Beyond that, the best I could advise, is to recreate the error that doesn't produce a message, and then slowly strip as much out of the script as possible whilst retaining the errant behaviour. Once you have something of a postable size, without to many non-standard dependancies, you could post that here and we would have an opportunity to try it and see if the problem is something confined to your system, version of Perl etc. Or a more generic problem. Examine what is said, not who speaks. "But you should never overestimate the ingenuity of the sceptics to come up with a counter-argument." -Myles Allen "Think for yourself!" - Abigail "Time is a poor substitute for thought"--theorbtwo "Efficiency is intelligent laziness." -David Dunham "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon	[reply] [d/l] [select]
Re^4: no error messages for syntax errors? by argv (Pilgrim) on Dec 06, 2004 at 04:11 UTC
well, as my previous post hypothesized, and you clarified in your reply, the error was indeed `CGI::Carp` redirecting stderr. The reason I didn't catch it before is still unclear, but it deserves attention because I think it has something to do with the order in which packages are included (via `use`). I am also curious about the same question I asked before, on whether it's kosher for a `package` to `use CGI::Carp`, or if that should always just remain in the main::module. I use a package that has some utility functions, but I only import the functions themselves. I assumed (naively and stupidly, because I never thoroughly read the doc on this narrower issue) that perl only includes those functions that you request, and leaves everything else alone. Apparently not. This also raises the problem I've had in other circumstances, where packages include functions from other packages, and if my perl code includes one or more of those packages, certain functions end up getting important more than they need to. Again, I just assume that perl will figure this out and all works fine. The problem I ran into, though, is that sometimes the function reference doesn't work, and I have to switch the order in which I list the "use" lines in the perl code to get it to work. Sometimes, even that doesn't work, and I'm forced to actually use `Package::function()` before it actually works. Clearly, I'm not experienced at writing packages, and while I go off and figure that out, perhaps we can bring resolution to the problem that started all this: is it wrong for a package to include cgi::carp? Dan Heller http://www.danheller.com	[reply] [d/l] [select]