From: Christoph Anton Mitterer <calestyo@scientia.org>
To: Harald van Dijk <harald@gigawatt.nl>, dash@vger.kernel.org
Subject: Re: wrong behaviour when unsetting/setting some variables
Date: Tue, 27 Feb 2024 04:28:46 +0100 [thread overview]
Message-ID: <fdaa6e5ea49f1eecae637929d8c3e7feb84bbd5e.camel@scientia.org> (raw)
In-Reply-To: <18ce9b6d-f9fa-467a-ab3b-5a4ddc5ed36b@gigawatt.nl>
On Tue, 2024-02-27 at 03:07 +0000, Harald van Dijk wrote:
> I suspect the reason you don't see it happen with TERM, LINENO, and
> HISTSIZE is because you have built dash in a configuration in which
> these variables are not special.
Ah, I see... well I merely took the Debian unstable version of it.
> For special variables, we get to
>
> flags |= vp->flags & ~(VTEXTFIXED|VSTACK|VNOSAVE|VUNSET);
>
> where we preserve the VEXPORT of the previous value. In case of
> VUNSET,
> we should not be doing that. I agree with your expectations, unset
> should clear the export attribute.
So is it really just:
--- a/src/var.c 2024-02-27 04:25:32.000000000 +0100
+++ b/src/var.c 2024-02-27 04:22:40.744456151 +0100
@@ -295,7 +295,7 @@
goto out;
}
- flags |= vp->flags & ~(VTEXTFIXED|VSTACK|VNOSAVE|VUNSET);
+ flags |= vp->flags & ~(VEXPORT|VTEXTFIXED|VSTACK|VNOSAVE|VUNSET);
} else {
if (flags & VNOSET)
goto out;
I had even had that before, and it seemed to work, but wasn't really
sure whether it doesn't mess anything up behind the scenes which I
didn't understand.
If so, are you going to send a proper - or shall I?
Thanks,
Chris.
next prev parent reply other threads:[~2024-02-27 3:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 2:07 wrong behaviour when unsetting/setting some variables Christoph Anton Mitterer
2024-02-27 3:07 ` Harald van Dijk
2024-02-27 3:28 ` Christoph Anton Mitterer [this message]
2024-02-27 10:24 ` Harald van Dijk
2024-02-27 4:23 ` Lawrence Velázquez
2024-02-27 5:11 ` Christoph Anton Mitterer
2024-02-27 7:53 ` Lawrence Velázquez
2024-02-29 12:29 ` Christoph Anton Mitterer
2024-02-29 17:58 ` Martijn Dekker
2024-02-29 19:03 ` Christoph Anton Mitterer
2024-02-28 0:56 ` Harald van Dijk
2024-02-29 12:24 ` Christoph Anton Mitterer
2024-02-29 18:03 ` Martijn Dekker
2024-02-29 17:41 ` Martijn Dekker
2024-02-29 18:07 ` Harald van Dijk
2024-02-29 18:45 ` Martijn Dekker
2024-02-29 18:56 ` Harald van Dijk
2024-03-10 21:33 ` Martijn Dekker
2024-04-11 1:26 ` Christoph Anton Mitterer
2024-04-11 7:43 ` [PATCH] var: Fix unexporting of local variables using unset Herbert Xu
2024-04-11 13:27 ` Christoph Anton Mitterer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fdaa6e5ea49f1eecae637929d8c3e7feb84bbd5e.camel@scientia.org \
--to=calestyo@scientia.org \
--cc=dash@vger.kernel.org \
--cc=harald@gigawatt.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox