Re^2: What is -w?

[htmanning]

Thanks. It enables warnings, which is what I suspected. The question is why a script wouldn't run without it if all it does is print warnings. I get all kinds of warnings in the logs with this script even though none of them seem to be serious or pan out. Most of them say I have a variable that is only used once, even though it is used in another required file. Thanks for the pointer. I'm still stumped as to why the script would return an error just because I wasn't printing warnings.

[Corion]

Most likely you are trying to run the script on a Unixish machine but the file uses Windows-style \r\n line endings.

If that is the case, the kernel will look at the file, see that it starts with #! and it will then read the line and try to execute the first word on that line as the interpreter. Likely, parsing for words only means "space or newline", so the kernel will see:

/usr/bin/perl\r

as the program to execute. There is no such program. Once you add -w to the command line, the kernel will see:

/usr/bin/perl -w\r

and use /usr/bin/perl as the program and -w\r as the first parameter to it. This starts Perl.

In any case, it is good to run with the -w switch always as this allows Perl to tell you about problematic things in your code.

[htmanning]

Thanks for the great explanation. I am on Ubuntu and all my other scripts work just fine. No line ending issues. I'm wondering if I have some weird routine or something, but I can't find it. Most of the warnings end up being wrong and it's just creating a massive log file. Anyway,I guess I have no choice because it will not run without it.

[hippo]

Most of the warnings end up being wrong and it's just creating a massive log file. Anyway,I guess I have no choice because it will not run without it.

You do have a choice - either live with the massive error log and have trouble finding a real problem in among all the noise or else fix the problems in the script which produce the noisy warnings in the first place. I strongly favour the latter.

If you do not know how to avoid one particular warning, you can post it here as an SSCCE and the monks can point you in the right direction.

If your script produces warnings and you don't even understand what the warnings mean, consider using diagnostics, but only on your dev environment (otherwise your log file will only get even more massive!).

Good luck.

[AnomalousMonk]

... all my other scripts work just fine. No line ending issues.

You need to focus your attention not on the scripts that work ok, but on the one that does not. In particular, and as suggested by Corion's post, I would look at a hex dump of the offending source file and compare it against other, well-behaved script files with an eye to line-ender infelicities.

And just to echo hippo's good advice while I'm at it, I would enable warnings (and strictures as well; see strict), although perhaps not globally but only locally, and clean up the problems exposed thereby.

[stevieb]

Corion may be onto something here regarding line-endings. If you want to check your file's line-endings specifically, you can use the following one-liner. It'll print out in hex the line ending for every line in the file, preceeded by the line number. Redirect it to a file if the list is too long for your console.

perl -wMstrict -nE 'say "$. ".unpack("H*",$1) if /([\n\x{0B}\f\r\x{85}
+]{1,2})/' file

Output:

1 0a
2 0a
3 0a
4 0a
5 0a
6 0a

That's a Unix style ending, (\n). For a Windows ending, you'd see 0d0a for \r\n, and for Mac (or possibly a broken Windows ending), 0d for \r.

If your endings aren't all the same, you can try running dos2unix at the command line, or in a vi/vim editor: :set ff=unix, then :wq.