Welcome!

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

SignUp Now!

Multiple commands and piping to a BTM

May
13,834
211
This works fine.

Code:
v:\> timer & echo foo | grep foo & timer
Timer 1 on: 18:13:14
foo
Timer 1 off: 18:13:14  Elapsed: 0:00:00.146

This doesn't work well (TIMER ON twice).

Code:
v:\> timer & echo foo | greptest.btm foo & timer
Timer 1 on: 18:19:21
foo
Timer 1 on: 18:19:21

Apparently the second TIMER is executed in the pipe instance. Why are the two command lines parsed/executed differently?

GREPTEST.BTM looks like this.

Code:
v:\> type greptest.btm
grep.exe %1
 
Another example.

Code:
v:\> echo %_pid & echo foo | greptest.btm foo & echo %_pid
8368
foo
5640
 
Code:
R:\>timer & (echo foo | greptest.btm foo) & timer
Timer 1 on: 20:12:36
m:grep.exe foo
foo
Timer 1 off: 20:12:38  Elapsed: 0:00:01.225

Joe
 
Code:
R:\>timer & echo foo |! greptest.btm foo & timer
Timer 1 on: 20:13:45
m:grep.exe foo
foo
Timer 1 off: 20:13:45  Elapsed: 0:00:00.205

Joe
 
Of the two examples,
I always prefer using the () instead of |!

In-process pipes create a temporary file.

Joe
 
Yes, I know those. But not having to use parentheses has been one of TCC bragging points (as opposed to CMD). And why is the behavior different for BTM vs. EXE?
 
Thanks for that. I didn't remember. But it doesn't answer the question of why it's different for BTMs and EXEs.

Note that my starting example in that thread used EXEs. So that has changed.
 
Nothing has changed in the way pipes are handled in the last several versions.

BTM's require an additional TCC instance to execute (TCC /C batname), EXE's do not.

You really need to start using command groups -- that's why they exist. And not using parentheses has never been a TCC "bragging point" (at least not by me!). You are relying on an imaginary parsing order (neither left to right, or right to left, but middle to one end or the other, depending on your mood).
 
As for the bragging point (maybe a poor choice of words) I was thinking of TCC's and CMD's handling of if cmd1 cmd2 & cmd3.

BTM's require an additional TCC instance to execute (TCC /C batname), EXE's do not.

It would seem that extra instance is getting the wrong command line.

You are relying on an imaginary parsing order (neither left to right, or right to left, but middle to one end or the other, depending on your mood).

I think in the absence of command grouping, &s (unprotected in any way) should divide the command line into multiple commands to be executed sequentially, left to right, by the current instance. If there is some other rule in play, please explain it to me.
 
It would seem that extra instance is getting the wrong command line.

Lacking command grouping or the DWIM feature, you're relying on the parser to guess what commands belong to what sessions. If you only complain once every few years, then the parser must be pretty good at guessing ...

I think in the absence of command grouping, &s (unprotected in any way) should divide the command line into multiple commands to be executed sequentially, left to right, by the current instance. If there is some other rule in play, please explain it to me.

With a simple single pipe, TCC executes the pipe child in a separate process, and then will try to move the following commands "up" to the original session. This is a very, very old "feature" going back to 4NT v2. It was implemented this way because DOS users were unable at that time to grasp the concept of pipe output happening in different sessions. (Also why "DOS pipes" |! were implemented.)

With multiple pipes, TCC has no way to determine which processes should be executed in which sessions, so everything gets run in new child sessions (left to right).

It's worked this way for 25 years. It is not going to change.
 
Back
Top