I agree with what you said but I found that on 2 of my own MS Windows web servers, where I had recently reinstalled the operating system and then installed ActiveState Perl 5.8, I noticed that although Fcntl has been installed and I can see the module in the lib folder, the @INC variable was not set up properly for IIS.

I realize this is easy to fix but it made me realize that even though Fcntl may be installed on many or all of my customers' web servers, it is likely that for some Fcntl will not be available through the web server without making a configuration change. The problem is many of my customers do not have the ability to change the configuration of their web servers. Many of them can only copy files. To accommodate these folks, it's important to be able to make Fcntl optional.

Thanks again.

Richard

If you go that far, you might not be able to rely on strict. At some point, you have to assume that your customers have non-broken systems. For me, that point is being able to use at least the core modules.

Thank you for your follow-up.

Well, the production version of my script doesn't actually rely on strict. Originally, I decided to not include use strict in the production version of the script to allow the script to run faster. But since my script doesn't use any module, it can run on configurations that do not have @INC set up properly, which I'm thinking may happen fairly often.

If I were to include use strict and use Fcntl in the production version of the script in the next version, I wonder how many people who upgrade will give me a call about the problem this exposes. I just don't see a reason why I need to go that route when I can avoid it.

Thanks again.

Richard