Re: zsh hangs loading init files

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jan 6,  8:27pm, Greg Klanderman wrote:
}
} hmm looks like users/14411

In that message, PWS pondered:

> I'm not sure why we don't check that commands are executables, was there
> ever a reason?

Apparently the answer is "Yeah, if you've got 10,000 executables or
a remote filesystem in your path, it takes a really long time to stat
them all."

On Jan 6,  8:36pm, Greg Klanderman wrote:
}
} Adding "setopt nohashdirs" gets me past the $(uname -s) quickly, but
} then later, accessing $commands[foo] still causes it to go stat()
} every file under every element of my path.

The zsh/parameter module uses the HASH_LIST_ALL option to determine
whether to fill the hash table when referencing $commands.  I'm not
sure that's documented anywhere ... this is also true for spelling
correction, so the part of the HASH_CMDS doc that refers to CORRECT
is at least incomplete.

Another way to cause the table to be filled is to use "whence -m".

On Jan 7,  2:56am, Mikael Magnusson wrote:
}
} There is no option to disable the stat()ing while filling the hash

Perhaps what should have been done is to stat them when reading them
back, but that would have required some state bits in the table.  An
option would be the next best thing.

} Incidentally, the manpage says
}        HASH_DIRS <D>
}               Whenever a command name is hashed, hash the directory
}               containing it, as well as all directories that occur
}               earlier in the path. Has no effect if neither HASH_CMDS
}               nor CORRECT is set.
} 
} However, setting hashdirs still causes the hash to be filled when both
} hashcmds and correct are unset.

Hrm.  I'm not able to reproduce that from "zsh -f".

torch% setopt no${^options[(I)hash*]}
torch% hash -r
torch% ls
...
torch% print $#commands
0
torch% setopt hashdirs
torch% ls
...
torch% print $#commands
0
torch%