From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11232 invoked from network); 8 Nov 2000 16:58:28 -0000 Received: from sunsite.dk (HELO sunsite.auc.dk) (130.225.51.30) by ns1.primenet.com.au with SMTP; 8 Nov 2000 16:58:28 -0000 Received: (qmail 19513 invoked by alias); 8 Nov 2000 16:58:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13142 Received: (qmail 19506 invoked from network); 8 Nov 2000 16:58:21 -0000 From: "Bart Schaefer" Message-Id: <1001108164839.ZM14072@candle.brasslantern.com> Date: Wed, 8 Nov 2000 16:48:39 +0000 In-Reply-To: <001b01c04980$bcd76c50$21c9ca95@mow.siemens.ru> Comments: In reply to "Andrej Borsenkow" "RE: PATCH: Run builtins, functions, etc. under zpty" (Nov 8, 3:38pm) References: <001b01c04980$bcd76c50$21c9ca95@mow.siemens.ru> X-Mailer: Z-Mail (5.0.0 30July97) To: "Andrej Borsenkow" , Subject: Re: PATCH: Run builtins, functions, etc. under zpty MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 ...) } (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.) } 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. The same set of terminal-initialization system calls that was happening before 13123 should still be happening, just in slightly different order because of using init_io() -- e.g. some calls that were previously made directly on the `slave' descriptor are now made on the dup'd copies of that descriptor. But that *shouldn't* make any difference -- unless ttyname(0) and ttyname(1) are both failing. } 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. } 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 } 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. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net