zsh-users
 help / color / mirror / code / Atom feed
* HASH_LIST_ALL does not work as expected
@ 2006-03-03  8:41 Com MN PG P E B Consultant 3
  2006-03-03 11:56 ` Peter Stephenson
  0 siblings, 1 reply; 3+ messages in thread
From: Com MN PG P E B Consultant 3 @ 2006-03-03  8:41 UTC (permalink / raw)
  To: zsh-users Mailinglist

Maybe I misunderstood the zsh documentation here, but...

I have set

setopt CORRECT_ALL
setopt CORRECT
setopt HASH_LIST_ALL
setopt HASH_CMDS

I understood that due to HASH_LIST_ALL, whenever I try to complete a
command, the 
PATH is hashed for available commands first.

It does not work that way. Here a simple example, assuming ~/bin is in
my PATH:

cd
echo "echo foo bar baz" >bin/dummy
chmod +x bin/dummy

Now due to HASH_LIST_ALL, when I press "dum" and the tab key to request
completions,
I would expect that "dummy" is shown - but it isn't.

However when I explicitly type

rehash

an then press "dum" + tab key, it is completed to "dummy".

Similarily, if I subsequently do a

rm bin/dummy

the command is *still* completed to "dummy" if completion is requested
(meaning again that the
hash is not updated).

I found this behaviour with zsh 4.0.7 running under Linux and 4.2.4
running undre Cygwin.

Ronald


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: HASH_LIST_ALL does not work as expected
  2006-03-03  8:41 HASH_LIST_ALL does not work as expected Com MN PG P E B Consultant 3
@ 2006-03-03 11:56 ` Peter Stephenson
  2006-03-03 16:46   ` Wayne Davison
  0 siblings, 1 reply; 3+ messages in thread
From: Peter Stephenson @ 2006-03-03 11:56 UTC (permalink / raw)
  To: zsh-users Mailinglist

"Com MN PG P E B Consultant 3" wrote:
> I understood that due to HASH_LIST_ALL, whenever I try to complete a
> command, the PATH is hashed for available commands first.

HASH_LIST_ALL means that the path is fully hashed *the first time* you
do completion, for efficiency.  For the same efficiency reasons, it
isn't rehashed automatically thereafter, which is the effect you are
seeing.

What you might want is always to complete commands by searching rather
than by the hash table.  I don't think that's currently supported.
(The implementation detail is that we use the zsh/parameter module's
special associative array commands to access the internal hash table.)

Actually, it would be trivial to make the shell issue a rehash on each
command search and nowadays (unlike the days when hashing of commands
was really useful) it doesn't take that long, at least unless you have
an NFS disk on a dial-up line from Ulaanbaatar.  This could be a style...
  zstyle ":completion:*" rehash true
will turn it on.

Index: Completion/Zsh/Type/_command_names
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Zsh/Type/_command_names,v
retrieving revision 1.7
diff -u -r1.7 _command_names
--- Completion/Zsh/Type/_command_names	1 May 2004 05:47:39 -0000	1.7
+++ Completion/Zsh/Type/_command_names	3 Mar 2006 11:50:36 -0000
@@ -6,6 +6,8 @@
 
 local args defs
 
+zstyle -t ":completion:${curcontext}:commands" rehash && rehash
+
 defs=(
   'commands:external command:compadd -k commands'
 )
Index: Doc/Zsh/compsys.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/compsys.yo,v
retrieving revision 1.183
diff -u -r1.183 compsys.yo
--- Doc/Zsh/compsys.yo	28 Feb 2006 11:57:20 -0000	1.183
+++ Doc/Zsh/compsys.yo	3 Mar 2006 11:50:37 -0000
@@ -2101,6 +2101,14 @@
 regular aliases will never be expanded.   If it is set to `tt(always)',
 regular aliases will be expanded even if not in command position.
 )
+kindex(rehash, completion style)
+item(tt(rehash))(
+If this is set when completing external commands, the internal
+list (hash) of commands will be updated for each search by issuing
+the tt(rehash) command.  There is a speed penalty for this which
+is only likely to be noticeable when directories in the path have
+slow file access.
+)
 kindex(remote-access, completion style)
 item(tt(remote-access))(
 If set to tt(false), certain commands will be prevented from making

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: HASH_LIST_ALL does not work as expected
  2006-03-03 11:56 ` Peter Stephenson
@ 2006-03-03 16:46   ` Wayne Davison
  0 siblings, 0 replies; 3+ messages in thread
From: Wayne Davison @ 2006-03-03 16:46 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: zsh-users Mailinglist

On Fri, Mar 03, 2006 at 11:56:59AM +0000, Peter Stephenson wrote:
> Actually, it would be trivial to make the shell issue a rehash on each
> command search and nowadays

Another possibility would be to run rehash in the precmd function.  This
would ensure that each command-line starts fresh.

..wayne..


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-03-03 16:46 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-03-03  8:41 HASH_LIST_ALL does not work as expected Com MN PG P E B Consultant 3
2006-03-03 11:56 ` Peter Stephenson
2006-03-03 16:46   ` Wayne Davison

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).