summary refs log tree commit diff
path: root/src/funcs/newgrp
diff options
context:
space:
mode:
authorHerbert Xu <herbert@gondor.apana.org.au>2021-05-17 15:19:23 +0800
committerHerbert Xu <herbert@gondor.apana.org.au>2021-06-04 11:38:06 +0800
commita53169826e4d941d454347c0f3bf0f98480dce86 (patch)
treed69f2e7bce6c889e96edd344fce54fa4a095bd82 /src/funcs/newgrp
parentRelease 0.5.11.3. (diff)
downloaddash-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 'src/funcs/newgrp')
0 files changed, 0 insertions, 0 deletions