From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8915 invoked by alias); 23 Apr 2015 04:56:02 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 34950 Received: (qmail 9073 invoked from network); 23 Apr 2015 04:55:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=TL7GgLcGeLchOblhvz9KyF2ivD1+z+YH+sr/2poJJpc=; b=keYCVZLMS5G1PtB7Fr43+tWFRWilUfgDlrSw0Ov4g1vdS0s81sQDHZ3rbI3ssL72fQ oigbLA3oTA4qBidpw7sIlpy146eF8AzOsxceZ9m98oTkzM9eZ9hA9ta1AclayeZ2eiFW Mt30u2c0bjxrBJH/rBnA7lY18+/Ke6kmA4+j9FpwFh16t6SsckRHwW8ZJWgHPnPH1+rc 1agLBqYgr8AtSveYA8drjPag6PGioaY9bRo/2uyYVyDQIXm7b1mdQKFoe/mv1LRpnR3C HqDYJ3LS8IuV5tfSxkbkzRJWHEU1lJ+QYWfh3bUJOEyZGu4+01H9BzwMFrfYHDrSjY46 nu0w== X-Gm-Message-State: ALoCoQlaz+qsSBCG3tiODSwt6rAvJqUOpEeuHmiYvraEw6KLCLEXXJkN+3v+V+yUzoIwn9GD5Edk X-Received: by 10.60.131.37 with SMTP id oj5mr815914oeb.77.1429764942489; Wed, 22 Apr 2015 21:55:42 -0700 (PDT) From: Bart Schaefer Message-Id: <150422215539.ZM14251@torch.brasslantern.com> Date: Wed, 22 Apr 2015 21:55:39 -0700 In-Reply-To: <20150422222627.1f6154e9@ntlworld.com> Comments: In reply to Peter Stephenson "Re: Using "source" in a function breaks job control" (Apr 22, 10:26pm) References: <5537E450.9060205@thequod.de> <20150422222627.1f6154e9@ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Hackers' List" Subject: Re: Using "source" in a function breaks job control MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Apr 22, 10:26pm, Peter Stephenson wrote: } Subject: Re: Using "source" in a function breaks job control } } > 1. echo true > /tmp/foo.zsh } > 2. vi() { source /tmp/foo.zsh; vim -u NONE -N; } } > 3. Run "vi" } > 4. In Vim, press Ctrl-Z to put it into the background. } > 5. Execute "fg". } > } > It should bring back "vim", but does not. } } I'm not going to get any further with this tonight, but using a build to } instrument process group handling I posted a few weeks ago it seems that } in the failing case the terminal doesn't get reattached to the vim } process when the shell function is brought to the foreground. It's not the "."/"source" command itself that's the problem, because it works fine as long as the sourced file does not execute any commands. vi() { source =(<<<'# Nothing here'); vim -u NONE -N } suspends/restarts fine. } In the failing case, } } There's no attachtty to 21065. Handling of SIGCONT within the subshell? I don't think so ... the fact that it prints zsh: running when you suspend it, indicates that pn->status == SP_RUNNING when passing through printjob(). Also (though perhaps not definitive), a TRAPCONT() handler does not fire in the subshell. It behaves differently (but still wrong) if the "source" file runs an external command: torch% vi() { source =(<<<'/bin/true'); vim -u NONE -N } torch% vi zsh: suspended torch% fg [4] continued torch% So there it believes WIFSTOPPED(pn->status) is true, but it still brings the wrong job into the foreground. (Actually there's a race condition here, if I "watch thisjob" with gdb I sometimes get "zsh: running" for an external command.) Finally you'll note that it has lost the jobtext in the failing case above, but in the successful case: torch% vi() { source =(<<<'# /bin/true'); vim -u NONE -N } torch% vi zsh: suspended vi torch% It has something to do with tracking the job table.