diff options
author | Herbert Xu <herbert@gondor.apana.org.au> | 2021-05-17 15:19:23 +0800 |
---|---|---|
committer | Herbert Xu <herbert@gondor.apana.org.au> | 2021-06-04 11:38:06 +0800 |
commit | a53169826e4d941d454347c0f3bf0f98480dce86 (patch) | |
tree | d69f2e7bce6c889e96edd344fce54fa4a095bd82 /debian | |
parent | Release 0.5.11.3. (diff) | |
download | dash-a53169826e4d941d454347c0f3bf0f98480dce86.tar.gz dash-a53169826e4d941d454347c0f3bf0f98480dce86.zip |
eval: Do not cache value of eflag in evaltree
Patrick Brünn <P.Bruenn@beckhoff.com> wrote: > > Since we are migrating to Debian bullseye, we discovered a new behavior > with our scripts, which look like this: >>#!/bin/sh >>cleanup() { >> set +e^M >> rmdir "" >>} >>set -eu >>trap 'cleanup' EXIT INT TERM >>echo 'Hello world!' > > With old dash v0.5.10.2 this script would return 0 as we expected it. > But since commit 62cf6955f8abe875752d7163f6f3adbc7e49ebae it returns > the last exit code of our cleanup function. > Reverting that commit gives a merge conflict, but it seems to fix _our_ > problem. As that topic appears too complex to us I want to ask the > experts here: > > Is this change in behavior intended, by dash? > > Our workaround at the moment would be: >>trap 'cleanup || true' EXIT INT TERM Thanks for the report. This is actually a fairly old bug with set -e that's just been exposed by the exit status change. What's really happening is that cleanup itself is triggering a set -e exit incorrectly because evaltree cached the value of eflag prior to the function call. This patch should fix the problem. Reported-by: Patrick Brünn <P.Bruenn@beckhoff.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Tested-by: Patrick Brünn <P.Bruenn@beckhoff.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'debian')
0 files changed, 0 insertions, 0 deletions