HUGO

Upper case letters in path causing match to fail

I have mounted a directory in my config.toml

[[module.mounts]]
source = "files/images"
target = "assets/images"

I can access these using match on the resources object:

{{ $images := resources.Match "images/**/*" }}

This returns all the images.

If I want images from a specific directory and that directory has uppercase letters like:

images/AFolderWithUpperCaseLetters/

Then I cannot match images within that folder. The following will return an empty list:

 {{ $images := resources.Match "images/AFolderWithUpperCaseLetters/*" }}

I I rename the folder to not have any uppercase letters then it correctly returns the images in the directory. This seems odd as the documentation claims match is case insensitive, and even odder because the case if he glob doesnt affect it, only the case of the actual directory path.

Am I doing something wrong?

On Ubuntu 20.04, Hugo Static Site Generator v0.74.3-DA0437B4/extended linux/amd64 BuildDate: 2020-07-23T16:30:30Z

Thanks

I don’t think so.

files
└── images
    β”œβ”€β”€ abc
    β”‚   β”œβ”€β”€ abc-1.jpg
    β”‚   └── abc-2.jpg
    └── ABC
        β”œβ”€β”€ ABC-1.jpg
        └── ABC-2.jpg
Code Finds Matches In
resources.Match "images/abc/*" images/abc
resources.Match "images/ABC/*" images/abc
resources.Match "images/aBc/*" images/abc

It looks as if the case normalization is performed on the provided pattern (making it lower case), not on the directory names.

But this is interesting:

Code Finds Matches In
resources.Match "images/*abc/*" images/abc and images/ABC
resources.Match "images/abc*/*" images/abc and images/ABC
resources.Match "images/a*bc/*" images/abc and images/ABC

So, your workaround is:

{{ $images := resources.Match "images/*AFolderWithUpperCaseLetters/*" }}

I think there’s a bug here somewhere. Normalizing the directory names as well as the pattern will lead to ambiguous results given my example of two directories with the same name but different cases. Perhaps the bug is in trying to normalize the pattern in the first place.

Relevant code:

1 Like

Thanks for the workaround, that sorts my problem for now. I will raise an issue on GitHub for the bug.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.