Path: csiph.com!goblin3!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: "Jason A. Donenfeld" Newsgroups: gnu.bash.bug Subject: Re: process substitution error handling Date: Thu, 6 Aug 2020 14:29:02 +0200 Lines: 59 Approved: bug-bash@gnu.org Message-ID: References: <20200420051508.GA2359844@zx2c4.com> <7496b183-2db3-6c03-6074-928adcd08f45@case.edu> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1596716960 30380 209.51.188.17 (6 Aug 2020 12:29:20 GMT) X-Complaints-To: action@cs.stanford.edu Cc: "bug-bash@gnu.org" To: =?UTF-8?B?T8SfdXo=?= Envelope-to: bug-bash@gnu.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=zx2c4.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type:content-transfer-encoding; s=mail; bh=S/dkP5q1APHU BnzSt9oP8yreXSU=; b=t9th2lrClOkn1rtORwuQ0Y5YXV/8DaMbvZ3g5nYpfF+c FptKQdH1mKhQPkKw1tf5yf8870Vwt53bXaujwnBWGG+HI6Pl61Iv8OPsxQTXyCdQ +7fNFMb9Nb7RMh626aGFbsSwI0yYsbjZ9UN6v32AvZJwi8lzTldACPD4rgARnUpR A4KvtL6MlKT4dHTcOxRwGHwGHUzpaaMSzsTKGBN947aI5hFn+xp/MBHkr7pA1sPh nL5C13ZWT6ghE7i84TIktv3MEa+Y8hvhooVXSWuPms6x+GtiPLPIdXJldy1H3kEk I/zz6QSGs3zcpHftluuf7D86wMy8rJZVYJOQzT4uoQ== X-Gm-Message-State: AOAM530sC+V51Uf7aqZohX/V1I97dHlPABgxnV+lgdvzJvjdLTeff0CX 1xCjfeRKkQxLODWUsfdcLHyBG4EQHYYYSdmQz18= X-Google-Smtp-Source: ABdhPJzzAmh+JEOJylN5tK5VYNY8ZrYjcA7IW76+qmzZw9VUqUi2be+bx81wgrraFQw4W4FP8EhQBeH57cpPh0FtOdA= X-Received: by 2002:a92:d2c8:: with SMTP id w8mr10860787ilg.38.1596716955364; Thu, 06 Aug 2020 05:29:15 -0700 (PDT) In-Reply-To: X-Gmail-Original-Message-ID: Received-SPF: pass client-ip=192.95.5.64; envelope-from=Jason@zx2c4.com; helo=mail.zx2c4.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/06 08:14:21 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: <20200420051508.GA2359844@zx2c4.com> <7496b183-2db3-6c03-6074-928adcd08f45@case.edu> Xref: csiph.com gnu.bash.bug:16707 On Thu, Aug 6, 2020 at 2:14 PM Jason A. Donenfeld wrote: > > On Thu, Aug 6, 2020 at 1:15 PM O=C4=9Fuz wrot= e: > > > > > > > > 6 A=C4=9Fustos 2020 Per=C5=9Fembe tarihinde Jason A. Donenfeld yazd=C4=B1: > >> > >> Hi, > >> > >> It may be a surprise to some that this code here winds up printing > >> "done", always: > >> > >> $ cat a.bash > >> set -e -o pipefail > >> while read -r line; do > >> echo "$line" > >> done < <(echo 1; sleep 1; echo 2; sleep 1; false; exit 1) > >> sleep 1 > >> echo done > >> > >> $ bash a.bash > >> 1 > >> 2 > >> done > >> > >> The reason for this is that process substitution right now does not > >> propagate errors. It's sort of possible to almost make this better > >> with `|| kill $$` or some variant, and trap handlers, but that's very > >> clunky and fraught with its own problems. > >> > >> Therefore, I propose a `set -o substfail` option for the upcoming bash > >> 5.1, which would cause process substitution to propagate its errors > >> upwards, even if done asynchronously. > >> > > > > set -e o substfail > > : <(sleep 10; exit 1) > > foo > > > > Say that `foo' is a command that takes longer than ten seconds to compl= ete, how would you expect the shell to behave here? Should it interrupt `fo= o' or wait for its termination and exit then? Or do something else? > > It's likely simpler to check after foo, since bash can just ask "are > any of the process substitution processes that I was wait(2)ing on in > exited state with non zero return?", which just involves looking in a > little list titled exited_with_error_process_subst for being non-null. > > A more sophisticated implementation could do that asynchronously with > signals and SIGCHLD. In that model, if bash gets sigchld from a > process that exits with failure, it then exits inside the signal > handler there. This actually wouldn't be too hard to do either. Actually, it looks like all the infrastructure for this latter approach is already there.