I think you need to show more context. That simple error is clearly diagnosed?

[22:21:13.09] P:\test>perl -c
s/foo/bar;
^Z
Substitution replacement not terminated at - line 1.
[download]

Is it possible that STDERR is being redirected somehow?

Updated after prematurely submitting!

[22:24:21.75] P:\test>perl -c 2>nul
s/foo/bar;
^Z
[download]

An alias for 'perl', or the PERL5OPTS env vars, or maybe a module you've starting using is redirecting STDERR to nul (/dev/null)?

...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?

My two trains of thought were:

1. 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?

2. 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