Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Help wanted with debugging a weird glob behavior

Indeed, I do have `nocaseglob` :) Can’t zsh be made to try to match the decomposed form, too? (Perhaps as a new option?) I don’t think putting `iconv`s everywhere is a sustainable practice …
Apart from that, I think it’s a good idea to create a helper script, `zsh-doctor`, that warns users of such possible edge cases in their config. It can check if they are on macOS and have nocaseglob enabled, and print an appropriate warning. In time, this script might save people a lot of trouble.
(github is probably a better home for such a diagnostic script, since it is more accessible and easier to do pull requests and stuff in …)

PS: I’m actually on APFS, not HFS. 

> On Aug 20, 2019, at 12:51 PM, Stephane Chazelas <stephane.chazelas@xxxxxxxxx> wrote:
> 
> 2019-08-20 12:21:44 +0430, Aryn Starr:
>> Indeed, using `echo "${$(cat path | iconv -f UTF-8-MAC -t UTF-8):h}”/*` works!
>> Seeing that `zsh -f` works correctly without this shenanigan, is there an option that disables this? I have oh-my-zsh installed, which might have set an option to that effect ...
> [...]
> 
> [back on-list]
> 
> You probably have the nocaseglob option on. That means that zsh
> does read the content of directories to find matches and since
> zreaddir returns é in its precomposed form (U+00E9), it matches
> neither e<U+0301> (the decomposed form of é) nor E<U+0301> (the
> decomposed form of É).
> 
> Not much you can do about it (except that iconv conversion or
> install a proper OS ;-)).
> 
> If you disable that zsh work around (for which I think you
> need to recompile zsh), then you'll probably get worse problems.
> 
> -- 
> Stephane
Messages sorted by: Reverse Date, Date, Thread, Author