in reply to Re: Can I include O_CREAT, O_EXCEL and O_WRONLY in my script without always requiring Fcntl?
in thread Can I include O_CREAT, O_EXCEL and O_WRONLY in my script without always requiring Fcntl?

Thank you for your help.

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

  • Comment on Re^2: Can I include O_CREAT, O_EXCEL and O_WRONLY in my script without always requiring Fcntl?
  • Select or Download Code

Replies are listed 'Best First'.
Re^3: Can I include O_CREAT, O_EXCEL and O_WRONLY in my script without always requiring Fcntl?
by chromatic (Archbishop) on Apr 13, 2006 at 21:51 UTC

    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

        You know your customers, but I certainly wouldn't do that. I've spent far too long holding the hands of customers who refuse to invest in a working platform (and I don't mean an operating system I like; I mean a system that functions) to invest much time and energy into workarounds for increasing levels of brokenness.

        If you can't count on a complete installation of the core system of Perl, I think you're in for a lot of trouble.