TPIPE.EXE doesn't import SetConsoleCtrlHandler().It does have a control handler. Won't help for this (somewhat contrived?) instance.
It'll also be a lot faster to redirect output to a file, and then have TPIPE read the file.
v:\> timer & (do x=1000001 to 1008389 ( echo %x %@repeat[x,990] ) ) | tpipe /simple=34 > nul & timer Timer 1 on: 22:33:15 Timer 1 off: 22:33:17 Elapsed: 0:00:02.85 v:\> timer & (do x=1000001 to 1008389 ( echo %x %@repeat[x,990] ) ) > cat1.txt & tpipe /input=cat1.txt /simple=34 > nul & timer Timer 1 on: 22:34:36 Timer 1 off: 22:34:39 Elapsed: 0:00:02.62
tpipe /input=cat1.txt /simple=34
I'm only reporting what I see.As it happens, I have the source code for TPIPE.EXE, and it definitely does set a console control handler. But it's irrelevant in your example, because you're killing a different process.
v:\> dumpbin /imports g:\tc14\TPipe.exe | grep -i console 19A GetConsoleCP 524 WriteConsoleW 1AC GetConsoleMode
If I use the Start\Run dialog to execute "g:\tc14\tpipe.exe /input=v:\tac1.txt /simple=34" I cannot interrupt it without getting "TPIPE.EXE has stopped working". IMHO, that should never happen (or be called WAD).
Hmmm! I think not being able to interrupt such a program is very significant. I hope they agree.I agree, but I also can't do anything about it. I've already passed it on to the developers, but I don't think it's significant enough to spend much time worrying about.