Re: command substitution: zsh waits until command exits

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 2,  3:16am, Vincent Lefevre wrote:
} Subject: Re: command substitution: zsh waits until command exits
}
} > } (I assumed asynchronously), but could replace the $(...) in some
} > } arbitrary order, once it knows the result, i.e. once the standard
} > } output is closed.
} > 
} > No, that would be non-deterministic with respect to left-to-right order.
} 
} But there can be the same kind of problem with process substitution.
} So, why allowing non-deterministic behavior for process substitution
} but not for command substitution?

Process substitution is opening a pipe to the process without remaining
in control of where the input or output is going; the process started
within a process substitution and the command executed dirctly by the
parent shell must run simultaneously to be able to communicate with each
other.  Process substitution wouldn't work at all if it were synchronous.

Command substitution, on the other hand, keeps control of the input and
output and must all be finished before the command line to be executed
by the parent shell is fully formed. It's impossible for the shell to
start the command before its argument list has been built; it's natural
for this to be a synchronous mechanism.
 
} > The default is to do everything synchronously.
} 
} How can the user know that?

That's part of the basic principles of how *nix shells work.  When you
execute something from the command line, and that something then closes
its standard descriptors, the shell doesn't immediately give you back a
prompt; it waits for the process to actually exit.  You have to tell it
when not to wait.

} > } >   echo $(coproc xterm -e 'tty >&3; sleep 999999' 3>&1 ; read -E <&p)
} > } 
} > } OK, thanks. But is there any reason why Ctrl-C doesn't work in the
} > } xterm?
} > 
} > Could be any of a variety of reasons, the most likely of which is that
} > no interactive shell is being run.
} 
} But Ctrl-C works with things like: xterm -e 'sleep 9999'

At this point I don't really know.  It could even be dependent on which
pseudo-tty device xterm happens to open and will seemingly randomly work
or not.  It could be that I got the syntax of -xrm wrong and you need
"XTerm*ttyModes: ..." -- better might be to just run "stty".

I'm not even sure what you mean by "works".  You mean ends the sleep?
It's possible that coproc is ignoring SIGINT and that's passed down
through xterm to sleep, so even though ^C is sending an interrupt the
sleep doesn't respond to it.  Yeah, that seems to be it; this causes
^C to end the sleep for me by changing it to a SIGQUIT:

  echo $(coproc xterm -e 'stty intr "" quit ^C ; tty >&3 ;
                          sleep 999999' 3>&1 ;
         read -E <&p)

Incidentally I use this little function all the time:

gdbterm () {
    xterm -title GDBterm -e sh -c 'exec xterm -e gdb --tty=$(tty) '"$*"
}