public inbox for dash@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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