From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=DKIM_ADSP_CUSTOM_MED, FREEMAIL_FROM,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 18bf4576 for ; Sun, 23 Feb 2020 01:10:13 +0000 (UTC) Received: (qmail 16096 invoked by alias); 23 Feb 2020 01:10:01 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: List-Unsubscribe: X-Seq: 24706 Received: (qmail 21709 invoked by uid 1010); 23 Feb 2020 01:10:01 -0000 X-Qmail-Scanner-Diagnostics: from mail-ua1-f48.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.102.2/25725. spamassassin: 3.4.2. Clear:RC:0(209.85.222.48):SA:0(-1.7/5.0):. Processed in 1.69031 secs); 23 Feb 2020 01:10:01 -0000 X-Envelope-From: rpigott314@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.222.48 as permitted sender) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JCYWVgrM2q0koWVpMVGfo77fao8li/EbE1k9+IHKdaE=; b=Wi8GOSMmWvsy1L4kC4Gbvd1KqTpst6COajmOMf4SmXNdNBPSSAMa1YvzzLoAC81S9j mw1YQXNZqkD7fRdKB1Rot7I3AM9kO+LwoiMKGZGoc7JX6xLbvb/xV5ClbFGOsUvx6Mhm 9dXNcvU88KvrF9SeOYGxv9WKKGbiW0AqUVzTJxLinmFLsRONY4IwSBhh5xdpxK7OIdQs 6CCtYgXEMp9+PuZESKB8ps5KcM/ssFY/WHYf5n1eYxdbd0kBrqAwH+SmmQ/I9ynOQP9Z Dxq68UEPTsOf7L+UGUxShaIp3Q+k2nMM+bxsomSVUcKG9jmliM4YVcOoYnxQ0oZt9IN7 n8Aw== X-Gm-Message-State: APjAAAX43o+H8xdQVcwHLMCjpOFbgcgEYxMEdwjdtX6RlEwnuFPKNl3t ymda+V10N4napGzior6+IIww6+ntMk2MfukgdS9Onr1p4A== X-Google-Smtp-Source: APXvYqzFETU6CPxNjSFtKXK09KUUQ9/3cgX7xRKs/ue/oh50mkzASWkFzI5+FXz82cwFG3SRBzxqRmYdfqJi9sZ+IJM= X-Received: by 2002:ab0:21cb:: with SMTP id u11mr21345359uan.16.1582420164551; Sat, 22 Feb 2020 17:09:24 -0800 (PST) MIME-Version: 1.0 From: Ronan Pigott Date: Sat, 22 Feb 2020 18:09:13 -0700 Message-ID: Subject: zsh mysteriously suspending job with sudo To: Zsh Users Content-Type: multipart/alternative; boundary="000000000000cb298f059f33e738" --000000000000cb298f059f33e738 Content-Type: text/plain; charset="UTF-8" Hello zsh users, I've encountered an unusual bug using zsh and I finally have a reliable reproduction so I'm looking for some insight. The issue is as follows: === $ sudo true [sudo] password for ronan: $ pacman -Qttdq | sudo pacman -Rns - [...] :: Do you want to remove these packages? [Y/n] zsh: done pacman -Qttdq | zsh: suspended (tty output) sudo pacman -Rns - === When I try to pipe a package list for pacman to read from stdin, the job is mysteriously suspended by zsh when "pacman -Rns -" prompts [Y/n] for confirmation to continue, before I have a chance to input anything. I have not input the SUSP character. The issue is also reproducible from a 'zsh -f' in a clean environment. Trying to 'fg' the suspended job always results in the following error: === $ fg[1] + done pacman -Qttdq | continued sudo pacman -Rns - zsh: can't set tty pgrp: no such process === I can only reproduce in zsh, not bash. The issue also only occurs when sudo *does not* prompt for a password, which is why I use a "sudo true" to temporarily authorize my user before demonstrating the issue. Bizarrely, the following examples all work as intended: === # with an extra file $ pacman -Qttdq > packages.txt; cat packages.txt | sudo pacman -Rns - [...] :: Do you want to remove these packages? [Y/n] # with an extra cat $ pacman -Qttdq | cat - | sudo pacman -Rns - [...] :: Do you want to remove these packages? [Y/n] # with process substitution $ sudo pacman -Rns - < <(pacman -Qttdq) [...] :: Do you want to remove these packages? [Y/n] === To exonerate pacman, a user from #archlinux helped create a script that exhibits similar behavior: === $ cat read-and-prompt.sh#!/bin/sh -- exec 3<&1 while IFS= read -r input; do printf '%s\n' "$input" >&3 done exec < /dev/tty printf 'prompt: ' >&2 read -r _ exec "$@" <&3 $ for a in a b c; do print "$a"; sleep 1; done | sudo ./read-and-prompt.sh cat a b c prompt:zsh: done for a in a b c; do; print "$a"; sleep 1; done | zsh: suspended (tty input) sudo ./read-and-prompt.sh cat === They also report that they cannot reproduce using doas in place of sudo. Considering the above, I believe my issue is a bug in either sudo or zsh, hence why I am asking here. Why is zsh suspending this job? My understanding is that jobs are suspended only in response to a signal, but I do not know where it could be generated in this case. --000000000000cb298f059f33e738--