From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25525 invoked by alias); 11 May 2013 22:40:22 -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: 31394 Received: (qmail 27425 invoked from network); 11 May 2013 22:40:16 -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,HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=aYFNHdqmnX2Bw/+NA8ZeRDvoi2yK7kjV5576o62DhJw=; b=bbLdxMZ27ylG4su2kK5rCuR4SirUb7inZo78KRbONnf9031MWwCaYBTvJDjBbRQGYG UkFKzpm1ToiJ05WAdg9Jb4Bpbn80zeSF0aRgQ0oaxx/APoWY81dSuYn2lhzFtuEpKLGS SjWYc581/cxhzflOmo4IzznNmumPlo4g2PVFeia72tNCEiBC1eW74gMX0a0F2EIgmCr/ jKZ/T7M/OPoA4q0MeIz66GMhsh7DzDPu2+rw2yC9hmZWpwZX5L79XsNASPX6m49HBVry ebqSzme4W2TkAsh02DhsjodFSRxrjnjScwwCvzOkeAzk5nxjMw3KsdL035ANd4cZzaru awhg== MIME-Version: 1.0 X-Received: by 10.112.163.135 with SMTP id yi7mr10052878lbb.72.1368312007670; Sat, 11 May 2013 15:40:07 -0700 (PDT) In-Reply-To: <01B63421-5BF1-4160-ABEA-FA799C10BF04@gmail.com> References: <01B63421-5BF1-4160-ABEA-FA799C10BF04@gmail.com> Date: Sat, 11 May 2013 15:40:07 -0700 Message-ID: Subject: Re: A tail of two situations From: Bart Schaefer To: Zsh hackers list Content-Type: multipart/alternative; boundary=089e01183bc828cdc204dc78f792 X-Gm-Message-State: ALoCoQnvpjCILy1C+lsWnUQ0pfkNuorDPX7DRLyuMxyIBXGp9yqMmeQvh7ApWaqz8E25ixD8wUtv --089e01183bc828cdc204dc78f792 Content-Type: text/plain; charset=ISO-8859-1 On Saturday, May 11, 2013, Jeremy Mates wrote: > > This seems inconsistent, as the behavior deep within ZSH (with MONITOR > set) depends on how(if) the program handles the ^C. Consistency in ZSH > demands either `unsetopt MONITOR` (subsequent code never run), or using > a subshell and trapping INT via a "function trap" Although this may seem inconsistent, the definition of signal delivery in Unix-like operating systems makes it difficult to do anything else. A signal may be delivered either to a single process, or to all processes in a single process group. As explained in the comment you quoted: > /* When MONITOR is set, the foreground process runs in a different * > * process group from the shell, so the shell will not receive * > * terminal signals, therefore we pretend that the shell got * > * the signal too. */ > For process groups, you can think of it as if the signal were percolating toward the root of the process tree from the leaf children. If the "leader" (closest to the root) of the signalled process group handles the signal, then that's the end of it; the only way its parent can determine what happened is by examining the exit status, which the child can set to anything it likes. (In your example there is only one process in the group, so the leaf is the leader.) For comparison, consider what you'd want to have happen if "tail" handled the signal and then proceeded without exiting, until it eventually exited with status zero somewhere down the line. To be "consistent" zsh could, when monitor is off, discard the signal that it recieves as the group leader and always run the next command, thus "pretending" that every foreground process is its own group leader; but that leads to things like shell scripts it is impossible to interrupt. (It's true there are other things that also lead to that, but they are less common.) The other option, when monitor is on, would be to create an extra zsh process whose sole job is to be the leader of every foreground process group, to be certain of receiving all signals and alerting the parent shell. This means doubling the number of forks on every command and having an otherwise useless extra copy of the shell hanging around, even though *most* processes are well-behaved and reveal the signal state in their exit status. In fact the reason you need the trap in the subshell is because zsh instead chooses to minimize the number of forks or extra copies of itself, and so exec's the subshell out of existence if it has no traps and only a single child to wait for. Originally (before the writing of the code that goes along with the comment you quoted), zsh "consistently" ignored whether the exit status indicated a signal and only responded to signals that it received directly. Users complained that this did not match expectation in the "well-behaved child" situation, and here we are. --089e01183bc828cdc204dc78f792--