Surely Perl knows this, since it may need to return there when the called script finishes.

For do, require, eval and sub calls, everything happens within Perl, so yes.

For the others, no. When Perl exits, the process simply stops doing anything. It doesn't control to the process that spawned Perl since it never stopped. Creating a child process is like creating a child person. You end up with two entities that operate independently. You can't return because the parent moved on.

How do I find the name of the script which called my current script, in Perl?

For calls within the Perl interpreter, (e.g. for do and require), Perl provides a wealth of information via caller.

For information about the parent process, you'll need an OS-dependent solution. There may be platform-independent and/or platform dependent modules that does this, but I haven't encountered them (or looked for them). Someone else will have to answer this part of the question.

If you're running under Unix (Mac is Unix), then the ps -aef command will show running jobs. ON my Mac ...

  UID   PID  PPID   C     STIME TTY           TIME CMD
    0     1     0   0   0:01.00 ??         0:01.38 /sbin/launchd
    0    11     1   0   0:00.82 ??         0:01.04 /usr/libexec/kextd
    0    12     1   0   0:07.11 ??         0:13.22 /usr/sbin/Directory
+Service
    0    13     1   0   0:01.11 ??         0:01.64 /usr/sbin/notifyd
    0    14     1   0   0:00.73 ??         0:01.57 /usr/sbin/syslogd
...
    0   347   346   0   0:00.02 ttys000    0:00.03 login -pf tomdlux
  503   348   347   0   0:00.11 ttys000    0:00.53 -bash
    0  3935   348   0   0:00.00 ttys000    0:00.00 ps -aef
[download]

You can see that this 'ps' command had Process ID (PID) 3935, and Parent ID (PPID) 348 ... that's a bash shell which was launched by 'login'

use English '-no_match_vars'; will allow you to use $PID or $PROCESS_ID to see your process id, as will getpid(), described in perldoc perlfunc. The parent id is fetched by getppid(). If you're multi-threaded on Linux, you'll want Linux::PID.

If you're on Windows, you're welcome to switch to Unix.

On Windows the Perl getppid is not implemented. I have used the following C code in some of my XS modules:

#include <windows.h>
#include <tlhelp32.h>

static int getppid(void) {

    HANDLE hToolSnapshot;
    PROCESSENTRY32 Pe32 = {0};
    BOOL bResult;
    DWORD PID;
    DWORD PPID = 0;
    
    PID = GetCurrentProcessId ();

    hToolSnapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    if (hToolSnapshot == INVALID_HANDLE_VALUE) {
        return 0;
    }

    Pe32.dwSize = sizeof(PROCESSENTRY32); 

    bResult = Process32First(hToolSnapshot, &Pe32); 

    if (!bResult) 
        return 0;
    
    while ( Process32Next(hToolSnapshot, &Pe32) ) {
        if (Pe32.th32ProcessID == PID) {
            PPID = Pe32.th32ParentProcessID;
            break;
        }
    }

    /* Expected */
    if (GetLastError() == ERROR_NO_MORE_FILES) {
        SetLastError(ERROR_SUCCESS);
    }

    return PPID;
}
[download]

Ah, I see you have upgraded to Linux, maybe it might be useful to some poor Windows coder.

How do I find the name of the script which called my current script, in Perl?

Now, a process may "call" another process (I presume with "call" you mean a regular fork/exec combo, and not some RPC or doors call, a knock on the window by a signal), but processes, they are like crossing deserts on horses - they have no names. Processes have numbers. And processes have an additional variable, which contains the number of their parent process. Which may be the process that forked/execed the current process, but it may not, as said process may have ceased to exist. In which case, the parent process is the init() process. (Well, on Unixy systems; I've no clue what happens on a Windows system)

XY Problem?

I can't help, this smells bad and will probably end as a maintainance nightmare.

I think perl scripts should not call each other. Start one perl script and share code by using shared modules instead of calling other scripts.

Depending on the name of the caller also "stinks", and I think it should be avoided (except for very good reasons -- like busybox). If you need different behaviour, call two different functions from the scripts. They can probably be as simple as ...

sub behaviourOne
{
    return commonCode('one');
}

sub behaviourTwo
{
    return commonCode('two');
}
[download]

Alexander

Thanks ikegami,

> For calls within the Perl interpreter, (e.g. for do and require), Perl provides a wealth of information via caller.

My current "need" (OK, whim) is for 'do', but the doco doesn't mention 'do' as something 'caller' works for.  I'll live.

Thanks JavaFan,

> (I presume with "call" you mean a regular fork/exec combo...

>> The call could be via a 'do' or 'system' or `` or 'exec'.

Thanks TomDLux,

> If you're on Windows, you're welcome to switch to Unix.

Well said!  Fortunately, I'm already on Linux.

Thanks to each of you for your good/prompt responses!

but the doco doesn't mention 'do' as something 'caller' works for.

What are you getting at?

The call could be via a 'do' or 'system' or `` or 'exec'.

system is fork+exec+wait

Hi ikegami,

What I'm getting at is, you said:

> For calls within the Perl interpreter, (e.g. for do and require), Perl provides a wealth of information via caller.

But in the 'caller' doco you linked to, I couldn't see any mention of 'do'.  It mentions 'require', etc., but not 'do'.