Hangs on inaccessible network file systems

[VorpalBlade]

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 believe ZSH_HIGHLIGHT_DIRS_BLACKLIST is sub-optimal and using some sort of background or helper thread would be a better option.

[phy1729]

Seems to be a duplicate of #885 .

[VorpalBlade]

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.

[danielshahaf]

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.

FWIW, if anyone runs into this, there's a number of workarounds, including zsh -c 'unmount /some/argument' and —

zsh% sh
sh$ unmount /some/argument
sh$ exit
zsh% 

. Or literally run ZSH_HIGHLIGHT_HIGHLIGHTERS=() at the prompt and restore that variable's value afterwards (default value is =( main )).

Anyway, let's resume discussions of the issue(s) and solutions to them :)