Using -- to terminate switch processing

[thelenm]

A fellow programmer was trying to convince me that the shebang line at the top of a Perl program should always end with "--". perlrun says that "--" on the shebang line terminates switch processing, so that no arguments after "--" are processed. My thinking is that switch processing terminates at the end of the shebang line anyway, so why should I use "--"?

I'm not a big fan of doing things without understanding why (i.e., cargo cult programming), so my question is this: do any of you Monks use "--" on the shebang line? If so, why? And what do you think of the contention that "all Perl programs should have -- on the shebang line"?

-- Mike

--
just,my${.02}

[tye]

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.
 $

So the practice does prevent one problem. Not one you are likely to run into, but a problem still.

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

    perl -w -e/test

(at least on some operating system / shell combinations) and it doesn't know that "-e/test" is the name of a script file instead of the "-e" option asking it to interpret the code "/test" (which causes it to complain about not finding the terminating "/" for that pattern match).

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

though. So I'm not sure what to advocate at this point.
                - tye

[roundboy]

The one place I've used -- in the shebang line was when I was writing scripts to run under SpeedyCGI. The speedy engine takes its own command-line arguments, which it looks for after the --. So a line might look like

  #!/usr/bin/perl -Tw -- -M10

but that's not exactly the end of the line.

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.

[BrowserUk]

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.

---

Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.

[Kanji]

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!

    --k.

[bsb]

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.

[skx]

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

#!/usr/bin/perl -w -- -*- cperl -*-

 Tongue firmly in cheek ;)

Steve
---
steve.org.uk

[rah]

On the shebang line seems unecessary to me (unless you have multiple options specified on the shebang line). On the command line makes more sense. "--" is a posix compliant way to end command line option processing via the getopt system command and is not limited to perl. It came into widespread use with the emergence of long form command line options (which usually begin with --). This removes some of the ambiguity that is present when both long and short options are valid. For example, if you saw:

$ mycommand -long

Is that -l -o -n -g, or the word long. With this:

$ mycommand --long

the intent is clear.

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.

[PodMaster]

I don't know about earlier perls, but from what I've seen of perl5 that is nonsense. Try it

$ cat bark
#!/usr/bin/perl

print " @ARGV 

";
__END__
$ ./bark -V
 -V

See. Perl doesn't try to interpret -V like it would if you said perl -V. It'd be stupid if it did, since you obviously didn't invoke perl, you invoked bark.

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.