¿Cómo puedo averiguar qué script, programa o shell ejecutó mi script de Perl?

Question

¿Cómo puedo determinar qué secuencia de comandos, programa o shell ejecutó mi script de Perl?

Ejemplo: Me gustaría tener salida legible para humanos si se ejecuta desde shell (personalizado para cada tipo de shell), un tipo diferente de salida si se llama como script de otro script perl y un formato legible por máquina si se ejecuta desde un programa como un servidor de integración continua.

Motivación: Tengo una herramienta que cambia su salida en función de qué shell lo ejecuta. Normalmente implementaría este comportamiento como una opción para el script, pero el diseño de esta herramienta no permite las opciones. Otros shells tienen variables de entorno que indican qué shell se está ejecutando. Estoy trabajando en un parche para admitir Powershell, que no tiene esa variable especial.

Editar: Muchas de estas respuestas son específicas de Linux. Desafortunadamente, Powershell es para Windows. getppid, la variable $ENV{SHELL}, y desgranar a ps no ayudará en este caso. Esta secuencia de comandos debe ejecutarse multiplataforma.

Answer 1

Dependiendo de su entorno, puede ser capaz de recogerlo desde las variables de entorno. Considere el siguiente código:

/usr/bin/perl -MData::Dumper -e 'print Dumper(\%ENV);' | grep sh 

En mi sistema Ubuntu, me obtiene:

'SHELL' => '/bin/bash', 

así que supongo que dice que estoy corriendo Perl desde un shell bash. Si usa algo más, la variable SHELL puede darle una pista.

Pero digamos que sabes que estás en bash, pero Perl se ejecuta desde una subshell. A continuación, intente:

/bin/sh -c "/usr/bin/perl -MData::Dumper -e 'print Dumper(\%ENV);'" | grep sh 

se encuentran:

 '_' => '/bin/sh', 
     'SHELL' => '/bin/bash', 

Así que la cáscara sigue siendo fiesta, pero fiesta tiene una variable $_ que también muestra el nombre de archivo absoluto del script de consola o en ejecución, lo que puede también da una pista valiosa. De manera similar, para otros entornos probablemente haya pistas en el hash perl %ENV que debería darle pistas valiosas.

Answer 2

Utiliza getppid(). Tome este fragmento en child.pl:

my $ppid = getppid(); 
system("ps --no-headers $ppid"); 

Si se ejecuta desde la línea de comandos, system mostrará bash o similar (entre otras cosas). Ejecútelo con system("perl child.pl"); en otro script, p. Ej. parent.pl, y verá que perl parent.pl lo ejecutó.

Para capturar sólo el nombre del proceso con argumentos (gracias a Ikegami para la sintaxis correcta ps):

my $ppid = getppid(); 
my $ps = `ps --no-headers -o cmd $ppid`; 
chomp $ps; 

EDIT: Una alternativa a este enfoque, podría ser la creación de enlaces de software a su secuencia de comandos, haga que los diferentes contextos utilicen diferentes enlaces para acceder a su secuencia de comandos e inspeccione $0 para crear lógica alrededor de eso.

Answer 3

Sugeriría un enfoque diferente para lograr su objetivo.En lugar de adivinar el contexto, hágalo más explícito. Cada caso de uso está completamente separado, por lo que tiene tres interfaces diferentes.

1. Función que se puede llamar dentro de un programa Perl. Esto probablemente devolvería una estructura de datos de Perl. Esto es mucho más fácil, más rápido y más confiable que analizar el resultado del script. También serviría como base para los scripts.

2. Secuencia de comandos que genera el shell actual. Puede mirar $ENV{SHELL} para descubrir qué shell se está ejecutando. Para los puntos de bonificación, proporcione un interruptor para invalidar explícitamente.

3. Una secuencia de comandos que se puede llamar dentro de un programa que no es de Perl, como su servidor de integración continua y emitir salida legible por máquina. XML y/o JSON o lo que sea.

2 y 3 sería sólo envolturas delgadas para dar formato a los datos que salen de 1.

Cada uno está diseñado para adaptarse a su necesidad específica. Cada uno funcionará sin heurística. Cada uno será mucho más simple que tratar de adivinar el contexto y lo que el usuario quiere.

Si no puede separar 2 y 3, haga que el servidor de integración continua establezca una variable de entorno y búsquela.

Answer 4

Esto es en Windows XP con PowerShell v2.0, así que tómelo con un grano de sal.

En una cáscara de cmd.exe, me sale:

PSModulePath=C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\

mientras que en la ventana de la consola de PowerShell, me sale:

PSModulePath=E:\Home\user\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsP owerShell\v1.0\Modules\

donde E:\Home\user es donde mi carpeta "Mis documentos" es. Entonces, una heurística puede ser verificar si PSModulePath contiene una ruta dependiente del usuario.

Además, en una ventana de la consola, me sale:

!::=::\

en el medio ambiente. Del PowerShell ISE, me sale:

!::=::\ 
!C:=C:\Documents and Settings\user

Answer 5

Si se está utilizando PowerShell 2.0 o superior (más probable), se puede inferir la shell como un proceso principal mediante el examen de la variable de entorno %psmodulepath%. Por defecto, apunta a los módulos del sistema bajo %windir%\system32\windowspowershell\v1.0\modules; esto es lo que vería si examina la variable desde cmd.exe.

Sin embargo, cuando se inicia PowerShell, deja por delante la ruta de búsqueda del módulo predeterminada del usuario a esta variable de entorno que se ve así: %userprofile%\documents\windowspowershell\modules. Esto es heredado por procesos secundarios. Entonces, su lógica sería probar si% psmodulepath% comienza con% userprofile% para detectar powershell 2.0 o superior. Esto no funcionará en PowerShell 1.0 porque no admite módulos.