WAD TPIPE.EXE has stopped working

[vefatica]

Interrupting this command with the console's "X" causes "TPIPE.EXE has stopped working (et c.)"

(do x=1000001 to 1008389 ( echo %x %@repeat[x,990] ) ) | tpipe /simple=34

 

[vefatica]

Interrupting this command with the console's "X" causes "TPIPE.EXE has stopped working (et c.)"

(do x=1000001 to 1008389 ( echo %x %@repeat[x,990] ) ) | tpipe /simple=34

Ctrl-C and Ctrl-Break have the same result.

 

[rconn]

WAD -- what would you expect it to do after you killed its input?

 

[vefatica]

WAD -- what would you expect it to do after you killed its input?

I'd expect it to do the same thing that SORT, GREP, FINDSTR, and dozens of other similar text utilities do, handle the event by exiting gracefully.

 

[rconn]

It's a third party dll.

 

[vefatica]

It's a third party dll.

I figured you wrote the EXE and could put a console control handler in it.

 

[rconn]

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.

 

[vefatica]

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.

TPIPE.EXE doesn't import SetConsoleCtrlHandler().

Writing to a file first is only a tad faster (and leaves an extra file hanging around).

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

And you also get "TPIPE.EXE has stopped working" when you try to interrupt the likes of:

tpipe /input=cat1.txt /simple=34

 

[rconn]

TPIPE.EXE doesn't import SetConsoleCtrlHandler().

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.

 

[rconn]

Writing to a file first is only a tad faster (and leaves an extra file hanging around).

Your test is a bit flawed, as it's spending most of its time in the DO loop, not in TPIPE. Your data set is also pretty small, which also skews the results.

 

[vefatica]

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.

I'm only reporting what I see.

v:\> dumpbin /imports g:\tc14\TPipe.exe | grep -i console
                  19A GetConsoleCP
                  524 WriteConsoleW
                  1AC GetConsoleMode

What other process? 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).

 

[rconn]

I'm only reporting what I see.

You can't see the whole file. Like the other .exe's, tpipe.exe is partially encrypted.

 

[rconn]

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).

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.

 

[vefatica]

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.

Hmmm! I think not being able to interrupt such a program is very significant. I hope they agree.

P.S., I was hoping you'd respond to "A question for Rex" in the plugins forum.