Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

perl vs she-bang perl

by mpersico (Scribe)
on Mar 06, 2013 at 21:37 UTC ( #1022100=perlquestion: print w/replies, xml ) Need Help??
mpersico has asked for the wisdom of the Perl Monks concerning the following question:

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

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

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?

The reason is that I am looking at the Restart functionality of the Devel::ptkdb debugger and the restart is hardcoded as perl -d:ptkdb -w originalScript originalArgs

If any other options were given to perl (-a, -n -e, etc) then the restart will be different than the original call.


Replies are listed 'Best First'.
Re: perl vs she-bang perl
by tobyink (Abbot) on Mar 06, 2013 at 22:45 UTC

    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 ./ looks like perl ./

    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.

    package Cow { use Moo; has name => (is => 'lazy', default => sub { 'Mooington' }) } say Cow->new->name
      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?
Re: perl vs she-bang perl
by BrowserUk (Pope) on Mar 06, 2013 at 22:29 UTC
    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.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: perl vs she-bang perl
by pvaldes (Chaplain) on Mar 07, 2013 at 10:39 UTC

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

    1) Was the script started via 'perl' or '' 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

    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?

    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

    print OUTFILE_LOG "Running as: ", $0," ",$ARGV[0]," ",$ARGV[1]," ",$ARGV[2]; #... etc
Re: perl vs she-bang perl
by mpersico (Scribe) on Mar 07, 2013 at 14:56 UTC


    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

    What command was used to start my script?

    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.


    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.


    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.


      Well, you can lie to exec about what $0 is in the first place (see 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 ? :-)

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1022100]
Front-paged by Corion
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (6)
As of 2017-01-17 06:09 GMT
Find Nodes?
    Voting Booth?
    Do you watch meteor showers?

    Results (152 votes). Check out past polls.