Re: command substitution: zsh waits until command exits

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2007-12-01 21:07:44 -0800, Bart Schaefer wrote:
> 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.

This could work: for <(...), zsh could start the process, redirecting
its output to a temporary file, and once the process has terminated,
zsh could run the command with a normal redirection, and clean up at
the end.

> 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 substituted command doesn't need to be finished to be able to build
the argument list: its standard output just needs to be closed (which
is what I did in my example). This is the same thing with a pipe: with

  { echo ab; sleep 5 } | cat

cat is still running during the sleep, but with

  { echo ab; exec 1>&-; sleep 5 } | cat

cat is no longer running during the sleep, as there can be no more
output. So, one could expect the same behavior with

  echo $(echo ab; exec 1>&-; sleep 5)

> } > 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.

That's only one particular example. But for instance, pipes are not
done synchronously: the second command is started before the first
command ends.

> } 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".

  echo $(coproc xterm -e 'stty -a ; tty >&3 ; sleep 999999' 3>&1 ;
         read -E <&p)

outputs

speed 38400 baud; rows 60; columns 80;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; status = <undef>; min = 1; time = 0;
-parenb -parodd cs7 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff
-ixany -imaxbel
opost -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab3 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -tostop -echoprt echoctl
echoke

in the xterm, but Ctrl-C still doesn't work.

> I'm not even sure what you mean by "works".  You mean ends the sleep?

Yes, i.e. behave as if there were no coproc.

> 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)

Yes, Ctrl-\ (quit with the default tty settings) has always worked.

> Incidentally I use this little function all the time:
> 
> gdbterm () {
>     xterm -title GDBterm -e sh -c 'exec xterm -e gdb --tty=$(tty) '"$*"
> }

but that's specific to gdb. And why starting two xterms?

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)