Devel::PL_origargv will tell you the arguments passed to Perl itself.

On Linux, I've not been able to figure out any official technique to determine whether or not the file was started via the shebang. If you go via /proc/$$/cmdline or similar, you just see a "rewritten" command line, so that a script started by typing ./script.pl looks like perl ./script.pl.

However, I have found an interesting heuristic that seems to work on my machine. If you read the 10th field from /proc/$$/stat (it's a number representing the number of minor page faults occurred during the running of the script), I've noticed it's about 25% higher when the script is run via a shebang.

Update:... hmm... interestinger and interestinger... I habitually use the shebang #!/usr/bin/env perl, but if you hard-code the path to the Perl executable (like #!/usr/bin/perl) then the second field of /proc/$$/stat is pretty clear.

Yep, #!/usr/bin/perl can be easy detected. It's even displayed differently in process list. As for /usr/bin/env - I suspect you can probably check parrent process and find its name?

2) Can I determine what options were passed to 'perl' for the former or what options were on the she-bang line for the latter?

1. On Windows you can obtain the command line used to run the current process.

   It requires using an external command (eg.): wmic process where ProcessId="$$" get commandLine

   Or via Win32::API or Inline::C

2. You might be able to get at the shebang line by (re)opening the DATA file handle and reading the first line.

Discussion:

Lots of good answers here. Thank you all.

After consideration of the responses, I can say that my first point would better be stated as

It's going to be either perl [perlargs] script ... or script ...

In the latter case, any Perl arguments are in the shebang line, but in the end, I don't care; if I restart the script the same way it was started, the Perl arguments will be applied the same way, and transparently if on the shebang line. Looking them up and applying them myself with an explict perl command would be inconsistent with the original start.

Solutions:

In *nix land, my best bet is to scrape a ps command. It gives me everything I need in one shot.

In Win* land, the wmic solution solution is perfect for my needs; it appears to be present in Windows all the way back to XP.

Followup:

So, if I wanted to bundle this all up in a module for CPAN, what do y'all think is a good name for the module and it's only function?

After I sent my reply above, I went off and did a rather involved exploration of /proc and ps that I was going to post here. But, as a result of that work, and a discussion of it with a colleague, I came to the conclusion that using any external means of determining a process' own start up command is potentially inaccurate and a potential security breach.

How?

Well, you can lie to exec about what $0 is in the first place (see http://perldoc.perl.org/functions/exec.html and search for lie). And the lie will be propagated in /proc and ps, so using those are no better than using $0. Additionally, I would imagine that mucking around with your environment (especially $ENV{PATH}) before calling exec on a naked perl command could be the potential security hazard.

I am convinced that the safest way for a Perl program to re-invoke yourself is to build the command as follows:

• Use $^X in place of the perl command you might determine externally.
• Use Devel::PL_origargv for arguments/options to Perl itself.
• Use $0 for the script name (although this can be fraught with peril, as noted above).
• Use a copy of @ARGV before any getopt processing.
• Put all of these in an array and use the exec(@array) form, not the exec("@array") string form.

Still sounds like an operation worth of a module. Potential names anyone? Reinvoke? Groundhog ? :-)

In a perl script, is there anyway to determine the following:

1) Was the script started via 'perl script.pl' or 'script.pl' using the she-bang line?

Is not much relevant. You could use head -1 myscript and see what is it the first line, and use ls -lh myscript to see if is executable. if both you could suspect that the script was launched as "./myscript", but the "perl myscript" form is also possible. If myscript is not executable or the shebang line is missing, you need to run this as "perl myscript"

Your answer is perhaps in bash history

mmh, only in bash history for the former, just looking at the shebang line for the latter. If you want to pick up this info from now on in a perl script you could put something like this in your script