Consider:

 $ mkdir ./-e
 $ cat >./-e/test
#!/usr/bin/perl -w
die "It ran!";
__END__
 $ chmod a+x ./-e/test
 $ ./-e/test
It ran! at ./-e/test line 2.
 $ -e/test
Search pattern not terminated at -e line 1.
 $
[download]

For that last command, perl gets executed with a command line that looks like:

    perl -w -e/test
[download]

I could envision some operating systems filling in the "--" for you such that including your own "--" would cause perl to report:

Can't open perl script "--": No such file or directory
[download]

  #!/usr/bin/perl -Tw -- -M10
[download]

As for putting it at the very end, I suppose that back in the days of 1200 baud modems and freaky line noise, it might have been handy for keeping any bogus noise chars from being interpreted as command-line args. But I sure can't think of any reason to do it now.

I'd have to ask you collegue: Why? What (potential) errors does the addition of the '--' prevent?

Whilst the system I use does not depend upon the shebang line to find the executable, it does respect most switches applied via a shebang line. Adding additional, non-switch tokens after the switches, with or without the presence of '--' has no discernable effect upon the function of the script. Therefore I see no reason to add the '--'.

I'd be interested to know if there are any effects or caveats that I haven't yet discerned.

What (potential) errors does the addition of the '--' prevent?

On systems that do depend on the shebang to find the executable, a stray carriage return (as so often happens when transferring files from Windows to Unix) can break that magic. Adding -- in such cases ensures that the trailing ^M never interferes with the binary name. Then again, adding ANY switch seems to accomplishes the same...

$ cat -e cM.pl
#!/usr/bin/perl^M$
^M$
print "Hello, World!";^M$

$ ./cM.pl
: bad interpreter: No such file or directory

$ cat -e cM--.pl
#!/usr/bin/perl --^M$
^M$
print "Hello, World!";^M$

$ ./cM--.pl
Hello, World!
[download]

    --k.

I hit this when using -F/pattern/ as the last argument on a shebang line moved to windows. So maybe it makes the script more portable. I'd prefer it if perl could take care of it though.

 Personally I do, but only so I can do this:

#!/usr/bin/perl -w -- -*- cperl -*-
[download]

 Tongue firmly in cheek ;)

$ mycommand -long
[download]

$ mycommand --long
[download]

With option processing that can handle both long and short forms of options, with and without args, you need a way to determine where option processing (and any associated args) ends, and where command arguments begin. Use "--" to define that endpoint.

If you use even moderately complex command option processing, e.g. with Getopt::Std, you will find times when you must terminate option processing with "--". However, I doubt in the shebang line is one of those places.

$ cat bark
#!/usr/bin/perl

print " @ARGV 

";
__END__
$ ./bark -V
 -V
[download]

MJD says you can't just make shit up and expect the computer to know what you mean, retardo! I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests. ** The Third rule of perl club is a statement of fact: pod is sexy.