When you run the batch file, once you get to the prompt of the secondary shell, you have a process tree like this:

cmd.exe ## running the batch file
    perl.exe ## running -e ... system()
        cmd.exe  ## 2
[download]

The second copy of cmd.exe (tagged ##2) is now in control of the console window hence the c:\tmp> prompt.

When you type ^C, all the processes in the tree receive the message. The action they take depends upon their nature.

1. The second shell does nothing except re-prompt, just as you see in a normal cmd window.
2. Perl.exe emits Terminating on signal SIGINT(2) and terminates.
3. the first level shell prompts with the normal (for a shell running a batch file) message:

   Terminate batch job (Y/N)?
   [download]

At this point, with the perl process having ended, the (grandparent/grandchild) relationship between the first and second shells has been broken and the (relevant) process "tree" has become:

cmd.exe  ## running the batch file
cmd.exe  ## 2
[download]

In other words, both shells are still running, but as peers. More importantly, they are sharing the same console session. And that is the source of your confusion.

When you see the prompt Terminate batch job (Y/N)?, you respond to it. The problem is, as both shells are sharing the console session, and both are looking for input, when you respond, it is the other shell that reads the response. It tries to run your 'Y' as a command and you get:

'y' is not recognized as an internal or external command,
operable program or batch file.

c:\tmp>
[download]

So now you think you are talking to the second shell and probably type a command. Say dir, and you get:

c:\tmp>dir
Terminate batch job (Y/N)?
[download]

Because this time, its the first shells turn to receive the input.

Think of it like talking to someone long distance on a call that has been routed via a satellite which introduces that 1/4 second delay into the conversation.

The way out of the impasse at the keyboard is to type exit in response to the Terminate batch job (Y/N)? message. The exit will actually be read by the secondary shell, and it will terminate.

Then hit enter and you will get the Terminate batch job (Y/N)? prompt again and this time your response will be seen by the "correct" (first) shell, as it is the only one still running:

Terminate batch job (Y/N)? exit

Terminate batch job (Y/N)? y

c:\test>
[download]

The solution to avoiding the creation of the problem would be for perl to ignore ^C until any active system call completed. Obviously, you can arrange this to happen yourself on a case by case basis using %SIG{INT}.

This means that the example using Ruby probably works because Ruby itself (by design) catches the interrupt before spawning a sub-process?

Thank you for your suggestions and your elaborate explanation. Actually, in my application it indeed makes sense to catch SIGINT in my Perl program, so this is what I will do.

-- 
Ronald Fischer <ynnor@mm.st>

This means that the example using Ruby probably works because Ruby itself (by design) catches the interrupt before spawning a sub-process?

Hm. The first thing is that Windows doesn't do signals. perl.exe simulates POSIX-style signal handling to some extent.

^C generates a "Console Event". How this is processed by related processes depends in large part by whether the processes share a console or not; and b) whether they are formally related into a process group or not.

For more of the gory details see the discussion about CREATE_NEW_PROCESS_GROUP in the Process Creation Flags passed to the CreateProcess() function. See also the related discussion for GenerateConsoleCtrlEvent Function.

There are several ways that Ruby might achieve it's behaviour. Without reading the source it isn't possible to know which is used.

---

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.

Windows7 won't change anything :)

What you have here, is cmd being cmd, the cmd way , and perl being perl

cmd.exe is a special kind of program

Instead of striking out the incorrect parts of my investigation below, everything is in readmore

call perl -le " $SIG{INT}=q[IGNORE]; $ENV{X}='Y'; $ret = system('cmd')
+; print qq[system returned $ret ]; "
[download]

But that still leaves the problem of being prompted by the original shell running the batch file

$ exit
system returned 0
Terminate batch job (Y/N)? y
[download]

$ exit
system returned 0
Terminate batch job (Y/N)? n
finished
[download]

I'm not sure how to signal to it, that everything is ok , no need to prompt, the answer probably lies in that dllhook business :/