By registering with us, you'll be able to discuss, share and exchange private messages with other members of our community.

SignUp Now!

Yipes, pipes!

On Win7/32 (no INI file, no TCSTART, no plugins) all of these put TCC into a semi-useless state (the console goes blank, no prompt appears, when I type, I get only underscore characters in odd places, internal commands appear to do nothing, commands that start GUI things work (though I can't actually see the command), there's no transient TCC). If I fart around for a while, issuing commands I can't see and which apparently produce no output, and then issue "CMD", CMD.EXE starts OK ... when I exit CMD I see the output of all that farting around and a new TCC prompt (apparently back to normal).
[/code]echo foo | tpipe /simple=6
echo foo | g:\tc24\tpipe.exe /simple=6
echo foo | g:\tc23\tpipe /simple=6
echo foo | ffind /t"foo"
echo foo | tee foo.txt[/code]

All of the above are OK in v23 on Win7/32 and v24 on Win10/64.
I'm pretty sure (not 100%) that those things worked a few days ago with build 29 because I first discovered it when using a BTM that I use often. Since it happens with no INI file, no TCSTART, and no plugins, I don't know where to look. Have you got any ideas? Is there an easy way to get the transient TCC to run without an INI file, TCSTART, or plugins?
OK, I got it. When experimenting with console buffers in a plugin, I had created a TCEXIT.BTM and put this in it.
noop %@consoleb[%_startbuf]
I removed _STARTBUF from the plugin and forgot about the TCEXIT file. So the transient instance was evaluating
when it exited. That was apparently switching to a new buffer. Should it do that (it is, I think, bad syntax)?

One thing I discovered in my experimenting was that a child same-console process shouldn't exit while using a buffer other than the one it started in.

While that TCEXIT was in place, I could replicate all the bad behavior like this:
start /c /b