RE: PATCH: Run builtins, functions, etc. under zpty

["Andrej Borsenkow" <Andrej.Borsenkow@mow.siemens.ru>]

>
> On Nov 8,  3:38pm, Andrej Borsenkow wrote:
> } Subject: RE: PATCH: Run builtins, functions, etc. under zpty
> }
> } Attempt to run any (external) command with zpty under Cygwin now
> results in:
> }
> } zsh: can't set tty pgrp: not owner
>
> Hrm.  Does the clone module fail under cygwin as well?  (I'm not sure
> how you would test it, frankly, but if you can think of a way ...)
>

I'm not sure how to do it (in clean way). Some explanation: the very first
cygwin program checks if it has valid console window. If not, it spawns a
thread that controls console IO and creates a pipe. The other end of this pipe
is then our terminal (it adds tty emulation, 'course). Every cygwin program
started in this conosle inherits this "tty". So, you do not have
"free-standing" ttys under cygwin and cloning to some busy (allocated) tty
probably fails as well.

> } (from child process) and hanging? zsh.
>
> Do you mean that the "can't set tty pgrp" message appears on the pty,
> that is, that you read it back with "zpty -r"?  (If it shows up on the
> parent zsh's tty, it can't be from the child, because stdin/out/err
> are dup2'd before any such message could be generated.)
>

Yes, I can read it witj zpty -r (this itself was not as easy :-)

> } This happens with the version of cygwin that did work before, so
> it is very
> } much related to the changes in zsh. The messages above comes from
> attachtty,
> } but I am not sure when it is executed
>
> The only way attachtty() gets called (with 13123 applied) is from init_io(),
> and the message above can only happen if tcsetpgrp() or ioctl(TIOCSPGRP)
> both failed.  This means that the old code at abount line 310 of (the pre-
> 13123) zpty.c must also have been failing, but was never testing its return
> value and so was silent.
>

Before I've seen external program attached to new tty. So, something must have
changed.

>
> } and what happens after this, i.e. why zsh apparently "hangs".
>
> Just to be sure I understand -- which zsh appears to be hung?  The parent
> from which you issued the zpty command, or the child that's supposed to
> be on the new pty?  I think you mean the child.
>

I mean the child. After this message  I do not get any output at all. It
simply does nothing.

> } That is what I have in process list:
> }
> } $ ps -l
> }       PID    PPID    PGID     WINPID TTY  UID    STIME COMMAND
> }      1696       1    1696       1696   0 1006 15:22:33 /usr/bin/bash
> }       580       1     580        580   1 1006 15:22:34 /usr/bin/zsh
> }      2328     580    2328       2328  -1 1006 15:22:52 /usr/bin/zsh
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
child
> }      2188    1696    2188       1904   0 1006 15:28:35 /usr/bin/ps
> }
> } for "zpty sh /bin/sh". Zsh does not appear to execute command at
> all, but it
> } does not exit either.
>
> The only thing that happens after attachtty() is that the command is
> executed with execode().  If attachtty() has failed, MONITOR will have
> been turned off (as well as INTERACTIVE) before execode() runs.
>
> To see whether the hang is execode()-related, try replacing that with a
> call to
> 	execve(findcmd(args[0], 1), args, environ);
>
> That should be at line 361 of zpty.c, as it stands in cvs.
>

I'll give it a try. I'm currently busy trying to solve cygwin select problem
:-) It did not work for master pty in the way zsh is using it. Zsh seems to be
good stress test for cygwin. If we had somebody with intimate knowledge of
both at the same time ... :-)

-andrej