Declined Passing Back Variables from Pipes

[Jay Sage]

I thought of this when experimenting with the new ability of FSEARCH to accept piped input. When used with a standard pipe, FSEARCH's system variables (e.g., _fsearch_matches) are not available after the command runs. Of course, one can use an in-process pipe, but one is liable to forget that. It would be nice if the variables could be passed back to the parent process.

1. Is it possible for system variables generated in a child TCC process to pass variables back to the parent? If not, issue closed.

2. Would it be very difficult to program this? If so, issue closed.

FSEARCH is one command where this would be useful. Perhaps there are others.

 

[Joe Caverly]

Yes, it is possible for variables generated in a child TCC process to be passed back to the parent.

You can use the SETP command to accomplish this.

You could use Shared Memory @SMOPEN.

You could use PSHELL to do this.

Joe

 

[Jay Sage]

This is not something that I want to do. I'm suggesting the Rex build it into commands that accept piped input and set system variables. Then one would not have to remember to use an in-process pipe.

 

[rconn]

This is not something that I want to do. I'm suggesting the Rex build it into commands that accept piped input and set system variables. Then one would not have to remember to use an in-process pipe.

This would be WAAAAAAY more complicated than telling people to use in-process pipes.

Which is what I'm telling you to use.

 

[Jay Sage]

OK. I think it would have been nice if the coding were simple enough. The current situation is ripe for error, since the command variables after a regular pipe have the wrong value (from a previous invocation of FSEARCH without piping).

Perhaps the help where it now says "FSEARCH will read from STDIN (i.e., usually a pipe) if you don't specify path / filename" could point out that the command variables will not be updated unless an in-process pipe is used. A second example could be included.

dir /s |! fsearch/t"file47"

 

[rconn]

That's no different than every other command you could run in a pipe. I don't think that repeating that a few hundred times in the help would be beneficial.

Child process pipes have been the standard for the last 25 years; I would hope that people have realized by now that environment and command variables in one process do not magically copy themselves into a parent process.

And the parent pipe process wouldn't even necessarily (or usually?) be TCC.

 

[Jay Sage]

That's no different than every other command you could run in a pipe. I don't think that repeating that a few hundred times in the help would be beneficial.

There would be no need for "repeating that a few hundred times". How many commands accept piped input and return command variables? That variable from FSEARCH might very likely be used in a script to find out if a search string was or was not found.

I was just scanning through the list in the help for "Command Variables" (to get an idea of any others associated with commands into which data might be piped) and I noticed that the _fsearch_* variables are missing.

 

[rconn]

There would be no need for "repeating that a few hundred times". How many commands accept piped input and return command variables?

Many -- when you add calling TCC sessions that take piped input and process it with a combination of commands & variable functions. Which would be a lot more commonly used than only piping from a TCC internal command to another TCC internal command.

I think it would be more likely that users will be piping to FSEARCH from an external app, not from TCC.

 

[Jay Sage]

I think it would be more likely that users will be piping to FSEARCH from an external app, not from TCC.

What does that have to do with it? All I was suggesting was that the help remind people that the command variables will not be returned from a normal pipe. This has to do with piping and the FSEARCH command, not with the source of the data that is being piped in to FSEARCH.

 

[rconn]

What does that have to do with it? All I was suggesting was that the help remind people that the command variables will not be returned from a normal pipe. This has to do with piping and the FSEARCH command, not with the source of the data that is being piped in to FSEARCH.

The point is you were asking for the variables to be sent back to the calling process, and in the usual case of the parent process not being TCC, there's no place for FSEARCH / TCC to send the updated command variables / system variables / environment variables.

Regarding the more general issue here that when you use a pipe in anything more recent than Windows ME you are running in a separate process - I think that is well established by this time and doesn't need to be explicitly mentioned in the TCC help for every command that can send STDOUT to a pipe and/or read STDIN from a pipe. Which is almost every internal TCC command, and most external console commands.

There is a trivial workaround that's been in TCC for many years, and that's to use the "in-process pipes" (which are actually just a > & < redirection).