zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: Re: [zsh 4.0.1-pre-2 bug] named directories disappear
Date: Wed, 4 Apr 2001 05:11:47 +0000	[thread overview]
Message-ID: <1010404051148.ZM31435@candle.brasslantern.com> (raw)
In-Reply-To: <200104030816.KAA12908@beta.informatik.hu-berlin.de>

On Apr 3, 10:16am, Sven Wischnowsky wrote:
}
} That's caused by adduserdir() in utils.c.  The test in utils.c:533
} succeeds when the local variable is set and then the namedir-entry is
} removed.
} 
} I'm not sure how we should solve this.  Maybe just make `hash -d x=...'
} set the parameter `x', too?  Once one has done the above, one can't
} set $x anymore anyway.

True, but that changes the sense of ${x:-...} tests.  Maybe that's not a
very significant concern ...

An even more radical suggestion:  remove the getnode2() test from the
condition at line 530, so that one must both set the parameter AND use
it in a ~param expression before the nameddirtab entry gets clobbered?

But, sigh, that would mean always looking up the parameter to see if
it had changed, which sort of spoils the purpose of the nameddir hash.

} Or maybe the other way round?  Use a flag in nameddirtab entries that
} says that the entry was added with `hash -d ...' and don't change or
} remove such entries when the corresponding parameter is modified?

How about this:

Insted of a flag, we store (pm->level + 1) in the nameddirtab entry.
`hash -d' sets this field to zero (as if locallevel == -1).

When a parameter is set or unset, the corresponding nameddirtab entry:
may be changed only if (nd->level > 0 || pm->level == 0), and
may be deleted only if (nd->level > pm->level).

This implies that entries created with "hash -d" can be removed either
with "hash -r" or by assigning to a global, but not by assigning to a
local; it also implies that if a nameddirtab entry is changed, then
either (1) the global parameter changed, or (2) there must be another
parameter (in a surrounding scope) from which the entry can be restored
when the current scope ends, or (3) there was no entry in a surrounding
scope.

It might be possible to do the equivalent with a couple of bits in the
existing nd->flags, because I think "deleted only if ((nd->level > 0 &&
pm->level > 0) || pm->level == 0)" is sufficient; so you need one bit
for "this was set with hash -d" and one bit for "this was set from a
local parameter", and then you can work it out.

My concern with any plan that locks nameddir entries is that a function
might set a local and then use it as a namedir, only to have that fail
because of a previous "hash -d".

I'm not sure there's any right way out of this, only a least wrong ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   


      reply	other threads:[~2001-04-04  5:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-03  8:16 Sven Wischnowsky
2001-04-04  5:11 ` Bart Schaefer [this message]

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=1010404051148.ZM31435@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=zsh-workers@sunsite.dk \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).