Hello,

I have a question on the internal processing of command pipes in Tcl.
When you open a command pipe via [open "|..."' r+] and run a tcl script,
the output is available as long as you use "puts" statements in the
code. However, if instead you return a value as the last command in the
script, that return value is lost.

Is there a way to capture the returns instead, or both?

More details:

I am reading the book The Tcl Programming Language, chapter 16 on pipes,
i.e., the construct known as [open "|..."].

So I wrote a simple script and saved it in a file as follows:

file name: c:/temp/sample.tcl
file data: puts "Current time: [clock format [clock seconds]]"

Following the advice there, I can call it like so:

set chan [open "|[list [info nameofexecutable]] C:/temp/sample.tcl" r+]
chan configure $chan -buffering line
gets $chan

And I can see the the printed output. However, if I change the
sample.tcl as follows,

return "Current time: [clock format [clock seconds]]"

then nothing is read from the channel.

On Sunday, May 22, 2022 at 6:02:30 PM UTC-7, saito...@gmail.com wrote:
> Hello,
>
[snip]

> Following the advice there, I can call it like so:
>
> set chan [open "|[list [info nameofexecutable]] C:/temp/sample.tcl" r+]
> chan configure $chan -buffering line
> gets $chan
>
> And I can see the the printed output. However, if I change the
> sample.tcl as follows,
>
> return "Current time: [clock format [clock seconds]]"
>
> then nothing is read from the channel.

I'm not sure what you expectation is here. The original script opens a pipeline to read the standard output of a process as if it were a file. When the original script writes to the standard output (using puts), then indeed the output is seen. When you change the script to omit generating standard output, then you seen nothing. That's sorta what I would expect. Not clear to me what your expectations were.

On 5/22/22 9:24 PM, mango wrote:
>
> I'm not sure what you expectation is here. The original script opens a pipeline to read the standard output of a process as if it were a file. When the original script writes to the standard output (using puts), then indeed the output is seen. When you change the script to omit generating standard output, then you seen nothing. That's sorta what I would expect. Not clear to me what your expectations were.
>
>

Hello,

I was interested in capturing the return value, but using the spawning
mechanism. But I see what you mean. Thank you.

On Monday, May 23, 2022 at 3:32:45 AM UTC+2, saito wrote:
> On 5/22/22 9:24 PM, mango wrote:
> >
> > I'm not sure what you expectation is here. The original script opens a pipeline to read the standard output of a process as if it were a file. When the original script writes to the standard output (using puts), then indeed the output is seen. When you change the script to omit generating standard output, then you seen nothing. That's sorta what I would expect. Not clear to me what your expectations were.
> >
> >
> Hello,
>
> I was interested in capturing the return value, but using the spawning
> mechanism. But I see what you mean. Thank you.

You've just discovered one difference between interactive and non-interactive tclsh: return values are printed (one per script) in interactive mode only.

Notes:
* This also means that string values are generated for all such return values (follow-up "shimmering").
* Another notable difference is the behavior of the unknown command (follow-up "tcl_interactive").

Am 23.05.22 um 03:02 schrieb saitology9@gmail.com:
> Hello,
>
> I have a question on the internal processing of command pipes in Tcl.
> When you open a command pipe via [open "|..."' r+] and run a tcl script,

What's your reason to run another Tcl script by this kind of "forking"?
Why do you not simply "source otherscript.tcl" to run it?

I can think of the following reasons:

- If it is to achieve true concurrency, then checkout the package Thread.

- If you just need isolation between both scripts, i.e. not to confuse
variable names, use namespaces or an object system like TclOO or snit.

- If it is for partially untrusted user scripts, use slave interpreters.

Christian