> Is there a way to identify when the output is being presented in a separate window (such that I could change the code so that the "Enter to close window:" prompt only appears in these cases)?

Yes you can, and the solotion was already at pm: Re: Re: Re: Parent process name but is slow because it processes all PIDs to get one matching $$ (I wonder if this can be shortened..) using the cpan Win32::Process::Info module.

Here an adapted solution:

use strict;
use Win32::Process::Info;

my $pihandle = Win32::Process::Info->new();
my @procinfo = $pihandle->GetProcInfo();

my $ParentPID;
my %ProcNames;

foreach my $PIDInfo (@procinfo) {
    $ProcNames{$PIDInfo->{ProcessId}} = $PIDInfo->{Name};

    if ($PIDInfo->{ProcessId} == $$) {
        $ParentPID = $PIDInfo->{ParentProcessId};
        last;
    }
}

print "Parent's name is [", $ProcNames{$ParentPID}, "]\n";


if ( $ProcNames{$ParentPID} eq 'OpenWith.exe' or $ProcNames{$ParentPID
+} eq 'explorer.exe') {
    print 'Press ENTER to close the window: ';
    <>;
}
else{ print "..exiting normally\n"; }
[download]

Calling the above program from command line (I always use the longhish form: perl program.pl because I do not want to mess with assoc and friends and .pl is associated just with the editor ;) the program exit directly:

Discipulus@works:D>perl parentpid01.pl

Parent's name is [cmd.exe]
..exiting normally
[download]

But right clicking the file and using Open with and browsing to the current perl.exe I get:

Parent's name is [explorer.exe]
Press ENTER to close the window:
[download]

Weirdly (well nothing is normal on this OS) the first time I got that the program was called by OpenWith.exe but once perl.exe is in the cached list of Open With.. the caller became explorer.exe which I suppose is the same if you double click it and you have its extension associated to perl.exe

L*

G'day Discipulus,

Firstly, sorry for the late response. I had some fairly major dental work last week: I've spent the last few days recovering and doing little else.

Thanks for the script and examples. I imagine that code could be put into a module; perhaps used something (very roughly) like:

...
use if $^O eq 'MSWin32', Win32::Exit::Prompt => 'exit_prompt';
...
exit_prompt() if $^O eq 'MSWin32';
exit;
[download]

That's still extra code for every script and, as you say, it "is slow".

As running Perl scripts directly from Win10, instead of from Cygwin, is likely to be an infrequent requirement for a $work task — at least for the time being — I'll probably be looking at handling this in the following order:

1. Run scripts without extra code from cmd.exe (see discussion under VinsWorldcom's response).
2. Run scripts without extra code from a possibly reconfigured PowerShell (see discussion under Orangutan's reply).
3. Run scripts with your extra code from anywhere.

— Ken

I think it has to do with how .pl files are handled by Windows. This may come down to `assoc` and `ftype` or maybe in the registry. For me (from a cmd.exe prompt, this won't work in PowerShell):

VinsWorldcom@:C:\Users\VinsWorldcom\tmp> assoc | find /i "perl"
.pl=Perl_program_file

VinsWorldcom@:C:\Users\VinsWorldcom\tmp> ftype | find /i "Perl_program
+_file"
[download]

Notice, the `ftype` command (for me) returns nothing, but if I look in my registry at HKEY_CLASSES_ROOT\Perl_program_file, I have some subkeys:

HKEY_CLASSES_ROOT
  Perl_program_file
    shell
      Execute Perl Program
        command = [REG_SZ] C:\Strawberry\perl\bin\perl.exe "%1" %*
[download]

Now when I run your commands, with ./ or .\ and with or without `perl` (and also with or without the .pl extension as I have my PATHEXT environment variable to include .pl) from PowerShell and / or CMD.exe, in all the combinations of the above criteria that make sense, I get the same output:

PowerShell

PS VinsWorldcom ~\tmp > .\test.pl
Platform: MSWin32
Executable: C:\Strawberry\perl\bin\perl.exe
Enter to close window:
PS VinsWorldcom ~\tmp > ./test.pl
Platform: MSWin32
Executable: C:\Strawberry\perl\bin\perl.exe
Enter to close window:
PS VinsWorldcom ~\tmp > perl .\test.pl
Platform: MSWin32
Executable: C:\Strawberry\perl\bin\perl.exe
Enter to close window:
PS VinsWorldcom ~\tmp > perl ./test.pl
Platform: MSWin32
Executable: C:\Strawberry\perl\bin\perl.exe
Enter to close window:
PS VinsWorldcom ~\tmp > ./test
Platform: MSWin32
Executable: C:\Strawberry\perl\bin\perl.exe
Enter to close window:
PS VinsWorldcom ~\tmp > .\test
Platform: MSWin32
Executable: C:\Strawberry\perl\bin\perl.exe
Enter to close window:
PS VinsWorldcom ~\tmp >
[download]

CMD (note: CMD.exe won't interpret / as \ like PowerShell does)

VinsWorldcom@:C:\Users\VinsWorldcom\tmp> .\test.pl
Platform: MSWin32
Executable: C:\Strawberry\perl\bin\perl.exe
Enter to close window:

VinsWorldcom@:C:\Users\VinsWorldcom\tmp> perl .\test.pl
Platform: MSWin32
Executable: C:\Strawberry\perl\bin\perl.exe
Enter to close window:

VinsWorldcom@:C:\Users\VinsWorldcom\tmp> .\test
Platform: MSWin32
Executable: C:\Strawberry\perl\bin\perl.exe
Enter to close window:

VinsWorldcom@:C:\Users\VinsWorldcom\tmp>
[download]

G'day VinsWorldcom,

I got the same as you for 'assoc' and 'ftype' in cmd.exe:

C:\Users\ken\tmp>assoc | find /i "perl"
.pl=Perl_program_file

C:\Users\ken\tmp>ftype | find /i "Perl_program_file"

C:\Users\ken\tmp>
[download]

In the registry, I have exactly the same as you (except I have C:\Users\ken\local\opt\strawberry_perl\5_030_000\install instead of your C:\Strawberry).

In your PowerShell output, you show everything output to the PowerShell, instead of the commands starting with perl being output in a separate window. Did you do something else to achieve that?

In cmd.exe, I get much the same as you:

C:\Users\ken\tmp>perl .\test_platform.pl
Platform: MSWin32
Executable: C:\Users\ken\local\opt\strawberry_perl\5_030_000\install\p
+erl\bin\perl.exe
Enter to close window:

C:\Users\ken\tmp>.\test_platform.pl
Platform: MSWin32
Executable: C:\Users\ken\local\opt\strawberry_perl\5_030_000\install\p
+erl\bin\perl.exe
Enter to close window:

C:\Users\ken\tmp>perl test_platform.pl
Platform: MSWin32
Executable: C:\Users\ken\local\opt\strawberry_perl\5_030_000\install\p
+erl\bin\perl.exe
Enter to close window:

C:\Users\ken\tmp>test_platform.pl
Platform: MSWin32
Executable: C:\Users\ken\local\opt\strawberry_perl\5_030_000\install\p
+erl\bin\perl.exe
Enter to close window:

C:\Users\ken\tmp>
[download]

So, the answer to Question 1 seems to be to remove the

if ($^O eq 'MSWin32') {
    print 'Enter to close window: ';
    <>;
}
[download]

and run all scripts from "cmd.exe".

— Ken

I didn't do anything different - all output showed in the PowerShell window I ran the command from - no new window was launched.

And just a note, I use PowerShell now exclusively - I never use CMD.exe anymore. PowerShell, I've learned, is sooooo much more capable and I've grown to love it over the past year (yes, I was a late adopter - much like how I'm now picking up Python much to my chagrin since everyone at $work uses it).

Hello Ken, I'm not a guru or a big fan of windows, but I think I can answer question 2.

It all comes down to how windows 'luanches/executes' the script. First I want to mention that (on my windows powershell at least), it does not complain if I type:

./pm_11105937.pl

.\pm_11105937.pl

perl ./pm_11105937.pl

perl .\pm_11105937.pl

.\pm_11105937.pl

./pm_11105937.pl

perl pm_11105937.pl

As for question 1 though, I'm not sure, but I think there would be a way to do it with some command-line switches, for which you might find some wisdom in perldoc perlrun.

Hope I could help shed some light at least.

G'day Orangutan,

Yes, I found out about the './ and '.\ early on when I tried just 'test_platform.pl'. There was a lot of output, which I won't post here; however, the last part of that had 'Suggestion [3,General]: The command test_platform.pl was not found, but does exist in the current location. Windows PowerShell does not load commands from the current location by default. If you trust this command, instead type: ".\test_platform.pl". ...'.

This is pretty much the same as UNIX-like systems when '.' is not in the path. Using my Cygwin:

$ test_platform.pl
-bash: test_platform.pl: command not found
$ ./test_platform.pl
Platform: cygwin
Executable: /home/ken/perl5/perlbrew/perls/perl-5.30.0/bin/perl
[download]

So, from PowerShell

perl test_platform.pl
perl ./test_platform.pl
perl .\test_platform.pl
[download]

all work identically to how I described 'perl ./test_platform.pl' in the OP. And

./test_platform.pl
.\test_platform.pl
[download]

both work identically to how I described './test_platform.pl' in the OP.

Anyway, what you've described regarding how the Perl interpreter is called, does make sense, and probably answers Question 2. It's a pity, because I'd prefer not to have to type 'perl' before every script name; still, it is only for a work project and won't generally affect me as I'm normally using Cygwin.

I also noticed that you'd signed up only a fortnight ago; so please accept a belated welcome to the Monastery.

— Ken

Hello again, I think I learned something too, cmd indeed does run either call of the script in it's own window, only powershell opens the other window. And yeah if it's only for a minor convenience I suppose it might not be worth sinking too much time into :), but to throw some other suggestions out there, there does seem to be alot of possible ways to configure the powershell, or maybe wrap the script in a batch file or call from a batch file, and there also seems to be a 'legacy console' mode for powersell but I havent tried it.

Thanks for the welcome.