From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: zsh-workers-return-43518-ml=inbox.vuxu.org@zsh.org X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 11872315 for ; Sat, 22 Sep 2018 18:55:14 +0000 (UTC) Received: (qmail 24143 invoked by alias); 22 Sep 2018 18:54:56 -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: List-Unsubscribe: X-Seq: 43518 Received: (qmail 19045 invoked by uid 1010); 22 Sep 2018 18:54:56 -0000 X-Qmail-Scanner-Diagnostics: from joooj.vinc17.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(155.133.131.76):SA:0(-1.9/5.0):. Processed in 1.789256 secs); 22 Sep 2018 18:54:56 -0000 X-Envelope-From: vincent@vinc17.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Date: Sat, 22 Sep 2018 20:54:48 +0200 From: Vincent Lefevre To: zsh-workers@zsh.org Cc: Joey Pabalinas , Bart Schaefer , Peter Stephenson Subject: Re: long-standing tty related issue: wrapped Emacs not suspended Message-ID: <20180922185448.GA21799@joooj.vinc17.net> Mail-Followup-To: zsh-workers@zsh.org, Joey Pabalinas , Bart Schaefer , Peter Stephenson References: <20180920123005.GA20647@zira.vinc17.org> <20180921175740.6ab97a81@pws-HP.localdomain> <20180922055148.dvmf7kvknnez3cvd@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180922055148.dvmf7kvknnez3cvd@gmail.com> X-Mailer-Info: https://www.vinc17.net/mutt/ User-Agent: Mutt/1.10.1+96 (4350694b) vl-108074 (2018-09-18) On 2018-09-21 19:51:48 -1000, Joey Pabalinas wrote: > Interestingly enough I did once run into a program that used a SIGCONT > handler, reset to default disposition in SIGTSTP handler, for some internal > callback-ish stuff. My guess was it assumed SIGCONT to be a "safe" sentinel > signal (while completely forgetting about its uncatchable brother SIGSTOP), > but cases like that are mostly just broken curiosities and definitely not > worth worrying about :) A SIGCONT handler can be useful for programs running under Grid Engine (together with a SIGUSR1 handler, as this signal is sent shortly before SIGSTOP). -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)