Cautionary note for Win32 users. This isn't restricted to Perl use, but I fell foul of it through Perl, so I'll note it here.
I'm generating filenames of the form "path/to/xyz.ext" programmically. The ".ext" part is constant, and the "xyz" are alpha-numeric. My program would run along fine for a while and then just hang.
After much debugging, the realisation seeped into my conciousness that each time the program hung, the current filename was "path/to/PRN.ext" or "path/to/PrN.ext" or some other combination of "(P|p)(R|r)(N|n)" as the filename.
A long forgotten memory recalled that under DOS, the name "PRN" was a pseudo-handle for the (parallel port?) print device, much like "CON" is a pseudo-handle for the console. I also recalled that these pseudo-handles were defined to be "considered to exists at all levels in the directory structure".
What this piece of legacy crap design means is that any attempt to use "PRN" or "prn" (etc.) as a filename (for output), regardless of it being prefixed with a path, and/or postfixed with an extension will result in a successful open. BUT attempting to write to it will attempt to write to the printer. In my case, where there is no printer attached, the write just hangs. I guess it may eventually time out, but if it does, it takes longer than I have the patience to wait.
As a workaround, pre- or post-fixing the name part with any characters, or switching to "ext.PRN" avoids the problem.
I've long enjoyed the shortness of prog >nul relative to prog >/dev/null, but it has it's downside!
In reply to Filenames of "PRN" (or "PrN" etc) on Win32. by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |