-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hangs on inaccessible network file systems #892
Comments
Seems to be a duplicate of #885 . |
Almost, it appears that they are talking about slow network file systems in general, while I'm talking about ones that time out/hang due to loosing connection. But I believe the solution would likely be the same in both cases. |
FWIW, if anyone runs into this, there's a number of workarounds, including
. Or literally run Anyway, let's resume discussions of the issue(s) and solutions to them :) |
If a network file system (smb, cifs, fuse.sshfs, indirect ones via KDE kio/Gnome gvfs fuse backends, etc) becomes inaccessible for whatever reason, accesses to those paths will hang. This is relevant to zsh-syntax-highlighting as when I try to unmount the file system in question, the path highlighter (that causes underlining of the path if it is valid) causes zsh to hang.
It would be good if this check could be done in a way that doesn't block the main zsh process (an async subprocess that is talked to via pipes perhaps?), or perhaps have a (very short) timeout, to allow recovery from situations like that.
EDIT: While
ZSH_HIGHLIGHT_DIRS_BLACKLIST
is a thing, these shares are normally fast enough. The problem is only when they become inaccessible. Thus I believeZSH_HIGHLIGHT_DIRS_BLACKLIST
is sub-optimal and using some sort of background or helper thread would be a better option.The text was updated successfully, but these errors were encountered: