`typeset -U' and exported tied parameters

`typeset -U' and exported tied parameters

[Bart Schaefer]

This has something to do with the FPATH problem (11281 et al.), but I still
don't know precisely what.

zagzig% echo $ZSH_VERSION
3.1.7-pre-3
zagzig% MANPATH=/usr/man:/usr/man:/usr/man 
zagzig% printenv MANPATH
/usr/man:/usr/man:/usr/man
zagzig% print $manpath
/usr/man /usr/man /usr/man
zagzig% typeset -U manpath
zagzig% printenv MANPATH
/usr/man:/usr/man:/usr/man
zagzig% print $MANPATH
/usr/man
zagzig% print $manpath
/usr/man

Note that although `typeset -U' has changed both the array and the tied
parameter, it has failed to update the exported copy of the tied parameter.

zagzig% MANPATH=$MANPATH
zagzig% printenv MANPATH
/usr/man

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

FUNCTIONS_INSTALL in Makefile's is not updated.

[Andrej Borsenkow]

Anybody noticed it? If you change it in configure.in and just run make,
then configure is recreated, config.status is recreated with new value for
this, but no Makefile is changed. I now have new value (with BSD, Aix
etc) in config.status and old value in all Makefiles.

May be it's me again ... but I have seen, that new config.status was rerun
to
recreate Makefiles.

If you just run config.status, than it creates Makefiles with correct
parameter. It also (for whatever reason) recreated config.h.

It is annoying when you update from CVS. Ideally, just 'make' should
suffice, but ...

-andrej

Re: FUNCTIONS_INSTALL in Makefile's is not updated.

[Bart Schaefer]

On May 10,  8:58pm, Andrej Borsenkow wrote:
} Subject: FUNCTIONS_INSTALL in Makefile's is not updated.
}
} Anybody noticed it? If you change it in configure.in and just run make,
} then configure is recreated, config.status is recreated with new value for
} this, but no Makefile is changed.

This should fix it:

Index: Config/config.mk
===================================================================
@@ -37,6 +37,6 @@
 	cd $(dir_top) && \
 	  CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= ./config.status
 
-$(dir_top)/Config/defs.mk: $(sdir_top)/Config/defs.mk.in
+$(dir_top)/Config/defs.mk: $(sdir_top)/Config/defs.mk.in $(dir_top)/config.status
 	cd $(dir_top) && \
 	  CONFIG_FILES=Config/defs.mk CONFIG_HEADERS= ./config.status

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

"Cancel" menu selection & Co?

[Andrej Borsenkow]

Currently, as soon as menu selection is started, there seems to be no way
to cancel it - that is, revert input line to original state. The closest
it, exit menu selection and hit Undo.

Does anybody really use ^G to switch from menu selection to menu
completion? I hardly see any point here. So, the suggestion is, to make ^G
really cancel selection and revert line to it's original state (before
match was inserted). This is also consistent behaviour for ^G, that
normally cancels actions in other places.

As a related (to me at least) question or request - is it possible to
enter menu selection immediately if list does not fit on screen? May be,
not always (if somebody just wants a list with ^D he prkbably does not
want menu selection). OTOH if menu selection can be quit with ^G it can be
used as replacement for listing, but replacement that supports scrolling,
paging, going back etc.

And it just ocured to me, that you may want to set completion (at least,
how the results are presented) differently for different widgets. One for
complete-word, another for delete-char-or-list etc. Is it
possible? E.g. enetr menu selection with complete-word, but show list
anyway with d-c-o-l.

-andrej

Re: "Cancel" menu selection & Co?

[Bart Schaefer]

On May 10,  9:14pm, Andrej Borsenkow wrote:
} Subject: "Cancel" menu selection & Co?
}
} Currently, as soon as menu selection is started, there seems to be no way
} to cancel it - that is, revert input line to original state. The closest
} it, exit menu selection and hit Undo.
} 
} Does anybody really use ^G to switch from menu selection to menu
} completion? I hardly see any point here. So, the suggestion is, to make ^G
} really cancel selection and revert line to it's original state (before
} match was inserted). This is also consistent behaviour for ^G, that
} normally cancels actions in other places.

I, too, would prefer this behavior.
 
} As a related (to me at least) question or request - is it possible to
} enter menu selection immediately if list does not fit on screen?

We discussed that, but I don't recall whether it's possible.  The doc
for the `menu' style doesn't mention it.

} OTOH if menu selection can be quit with ^G it can be
} used as replacement for listing, but replacement that supports scrolling,
} paging, going back etc.

Listing already supports scrolling; set the LISTPROMPT parameter.  There's
a list-prompt style, too.

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

FPATH non-bug (Re: `typeset -U' and exported tied parameters)

[Bart Schaefer]

On May 10,  3:59pm, Bart Schaefer wrote:
} Subject: `typeset -U' and exported tied parameters
}
} This has something to do with the FPATH problem (11281 et al.), but I still
} don't know precisely what.
[...]
} Note that although `typeset -U' has changed both the array and the tied
} parameter, it has failed to update the exported copy of the tied parameter.

And that may very well, in fact, be the entire bug.  I now think the rest
was just pilot error on my part.

Unlike MODULE_PATH, which zsh never imports from the environment, FPATH
can be imported.  I didn't realize that; `autoload -U' was failing in an
older version of zsh that was found first in my $path, which I believed
was 3.1.6-whatever because the value of $fpath [which I assumed was the
same as that created in setupvals()] pointed at the newer functions.

The older version of zsh then changed fpath, which changed the exported
FPATH, which was then imported again when my .zprofile detected the old
zsh and exec'd the newer version.  At that point the xtrace output of the
two branches of the `if (autoload -U)' became indistinguishable[*], which
contributed to my delusion that the new zsh was taking the wrong branch.

[*] They wouldn't have been indistinguishable if I'd moved my setting of
PS4 into .zshenv, but like an idiot I avoided that because the new value
won't work in the older zsh.

So I apologize for bothering you all with my stupidity; at least maybe we
can get `typeset -U' fixed (it's broken in 3.0.7 as well, BTW).

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

Re: `typeset -U' and exported tied parameters

[Peter Stephenson]

"Bart Schaefer" wrote:
> Note that although `typeset -U' has changed both the array and the tied
> parameter, it has failed to update the exported copy of the tied parameter.

This is the easy fix.  This is similar to the same problem with
lower/uppercasing of parameter.  I didn't look further because we sort of
agreed that parameter getting and setting could do with a complete
rewrite.  (The number of things we've agreed over the years could do with a
complete rewrite is large.  It's an immensely satisfying and timesaving
thing to do.  Unfortunately it doesn't get anything fixed.)

The change to uniqarray() is just because no-one was using the return
value.

Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.14
diff -u -r1.14 builtin.c
--- Src/builtin.c	2000/05/05 07:42:36	1.14
+++ Src/builtin.c	2000/05/10 19:04:25
@@ -1607,11 +1607,20 @@
 	}
 	if ((on & PM_UNIQUE) && !(pm->flags & PM_READONLY & ~off)) {
 	    Param apm;
-	    if (PM_TYPE(pm->flags) == PM_ARRAY)
-		uniqarray((*pm->gets.afn) (pm));
-	    else if (PM_TYPE(pm->flags) == PM_SCALAR && pm->ename &&
-		     (apm = (Param) paramtab->getnode(paramtab, pm->ename)))
-		uniqarray((*apm->gets.afn) (apm));
+	    char **x;
+	    if (PM_TYPE(pm->flags) == PM_ARRAY) {
+		x = (*pm->gets.afn)(pm);
+		uniqarray(x);
+		if (pm->ename && x)
+		    arrfixenv(pm->ename, x);
+	    } else if (PM_TYPE(pm->flags) == PM_SCALAR && pm->ename &&
+		       (apm =
+			(Param) paramtab->getnode(paramtab, pm->ename))) {
+		x = (*apm->gets.afn)(apm);
+		uniqarray(x);
+		if (x)
+		    arrfixenv(pm->nam, x);
+	    }
 	}
 	pm->flags = (pm->flags | on) & ~(off | PM_UNSET);
 	/* This auxlen/pm->ct stuff is a nasty hack. */
Index: Src/params.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/params.c,v
retrieving revision 1.7
diff -u -r1.7 params.c
--- Src/params.c	2000/04/27 08:21:10	1.7
+++ Src/params.c	2000/05/10 19:04:35
@@ -2299,10 +2299,9 @@
 }
 
 /**/
-int
+void
 uniqarray(char **x)
 {
-    int changes = 0;
     char **t, **p = x;
 
     if (!x || !*x)
@@ -2312,10 +2311,8 @@
 	    if (!strcmp(*p, *t)) {
 		zsfree(*p);
 		for (t = p--; (*t = t[1]) != NULL; t++);
-		changes++;
 		break;
 	    }
-    return changes;
 }
 
 /* Function to get value of special parameter `#' and `ARGC' */
@@ -2759,7 +2756,7 @@
  * do the replacing, since we've already scanned for the string. */
 
 /**/
-static void
+void
 arrfixenv(char *s, char **t)
 {
     char **ep, *u;

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk