use strict (upper or lower case)

[Anonymous Monk]

Please advise difference between:
use strict;

and

use Strict;

On my NT is seems to pull up alot of errors with "use strict" in my script, but doesnt pull up any errors with "use Strict".

[Abigail-II]

That's because of NT's case insentive filesystem. If you do use Strict, perl goes looking for a file call Strict.pm. It will find it - because there's a file stict.pm, and NT can't tell the difference.

Having found that, Perl compiles (and runs) the code in the file, and then goes looking for a sub Strict::import. It doesn't find it, so it continues compiling the rest of the code. However, there's a strict::import, which would have been found, and called, had you used use strict. And that would pull up all the (possible) errors in your code.

So, use use strict. It will not only improve your code, but it will also mean your code will not stop compiling at one of the first lines would you ever try to run it on a system where a normal filesystem.

Abigail

[Arien]

To start with your question: The correct form is use strict;

I can't verify what you're seeing on NT at the moment, but on Win98 I get this using ActiveState's port (Build 633):

1. use strict; works as expected and reports what it's supposed to.
2. use Strict; shows no errors indicating that Strict.pm cannot be found, but doesn't flag any non-strict code, so it is obivously not being hooked up.

This is a bug due to the fact that filenames under Windows are not case-sentitive: the file strict.pm can be found as Strict.pm. So when Perl goes looking for Strict.pm, strict.pm is found and loaded. However, the import sub will not be run (and the hints for the Perl parser don't get set) as would happen automatically if you use strict;.

— Arien

Edit: Abigail-II said most of this and said it faster...

[Anonymous Monk]

My script is too long to list. Is the use of "use warnings" okay instead? My script works fine with "use warnings".

[frankus]

Rule of thumb is lcfirst for pragmata names, ucfirst the rest.

Not sure if this is a foible with the distribution you're using. AFAIK strict is a pragma so should be lcfirst.

--

Brother Frankus.

¤

[RollyGuy]

The errors mean that strict is working. Stick with the lower-case version as this is the correct one. When you say "use strict" you should expect errors as this is forcing you to write good code.

The fact that "use Strict;" does not give you errors is interesting. It suggests that you have a package somewhere named Strict.pm. One more bit of knowledge is that the standard for package names is for them to start with upper-case so that they don't interfere with perl's pragmas like strict.

[higle]

Errr...

Well, I don't know about NT, but in my Unix environments, "Strict" is an invalid pragma, because the name of the strict module on these machines is "strict.pm".

Check your lib directory, and see what your strict module is named. It might be called "Strict.pm", instead of "strict.pm", or there may be a duplicate module called "Strict.pm".

The errors are probably because "use strict;" is working, and your code isn't :c)

?

  higle

[tye]

use Strict; is a rather complex no-op. It does nothing of consequence (other than confuse people reading your code into thinking it might do something).

use strict; gives you lots of errors because that is what it is supposed to do. See strict.pm for a little discussion about why you might want to have all of these errors generated. The basic idea is that use strict makes it more likely that you'll find a mistake early and thus save you a lot of time. But using it requires a few basic changes to the way you write scripts (you have to declare your variables so it can tell when you mispel a variable name, for example).

As already mentioned, the reason "use Strict;" does nothing silently is partly because Win32 file systems ignored the case of letters in file names. Well, that is part of the reason. The other part of the reason is that Perl (stupidly, IMO) doesn't complain when you include a module via one name but that module doesn't actually go by the name you gave.

You can run into the same problem quite a few other ways. For example, you might try to install Bogon::Quartz for your web page where you don't have "shell" access so you put the Quartz.pm file on the server and figure out that use Quartz; doesn't complain about anything and then you can't figure out why this module doesn't work like the documentation says it should. Perl should really tell you that use Quartz; did not find any module called "Quartz" even though it found a Quartz.pm file. There are even more ways to run into this problem if you are working on writing a module yourself.

So, in the end, it would be really nice if UNIVERSAL::import() complained when you used a module that didn't match the namespace you requested. You might find Universally unimportant and overused useful (and important).

        - tye (but my friends call me "Tye")

[chromatic]

What would this version of UNIVERSAL::import() do when it encountered a module that defined and inherited no import()?

[tye]

If you follow the link I gave, you'll find code that includes:     die "$pack->import() called for empty package!\n" Tho, the test isn't simply "doesn't define import()". Note that 'die' should probably be 'croak' and the '!' isn't necessary. (:

The linked-to code assumes you are on Win32 and so jumps right into looking for a simple letter case mismatch. That'd be very nice to keep but it might be good to make it not look for letter case mismatch on operating systems that don't typically ignore case in their file systems (then again, maybe not).

And, of course, there'd be a perldiag entry that explains other common ways this mistake happens. (I already described two of the big three, the third one being that you simply got your "package" statement wrong in the module you are writing.)

To get this into the Perl core, there should probably be an XS version of UNIVERSAL::import that does "require UNIVERSAL" to replace itself the first time it gets called.

        - tye (but my friends call me "Tye")

[joshua]

It would been nice if you would post your code... Here's what my theory is (w/o seeing any code):

1. When you use capital "S" it's not finding the Strict module because it doesn't exist. It's named "strict.pm" NOT "Strict.pm"
2. Your code has things (or the lack therof) in it that strict doesn't like: e.g. undefined varibales etc. The reason why you're getting errors (you didn't post what your errors were either!) when you spell it correctly is because _it_is_ finding the strict.pm module.

Joshua

Update: Fixed a couple typos.
Update 2: um, the Strict module _has_to_ exist otherwise you'll get errors. my bad :)