Upper case letters in path causing match to fail

[rhyst]

What version of Hugo are you using (hugo version)?

$ hugo version
Hugo Static Site Generator v0.74.3-DA0437B4/extended linux/amd64 BuildDate: 2020-07-23T16:30:30Z

Does this issue reproduce with the latest release?

yes

Probably easiest to read jmoorings comment on the forum:
https://discourse.gohugo.io/t/upper-case-letters-in-path-causing-match-to-fail/28069

Basically there seems to be an issue when matching folder names that have upper case letters in. jmooring suggests it is because case normalisation is being done on the pattern, rather than on the directory path.

[kc0bfv]

I accidentally duped this bug (as jmooring noticed) - but it still happened 29 days ago on the most recent hugo back then:

hugo v0.81.0-59D15C97 linux/amd64 BuildDate=2021-02-19T17:07:12Z VendorInfo=gohugoio

[rodrigoalcarazdelaosa]

I accidentally duped this bug (as jmooring noticed) - but it still happened 29 days ago on the most recent hugo back then:

hugo v0.81.0-59D15C97 linux/amd64 BuildDate=2021-02-19T17:07:12Z VendorInfo=gohugoio

Still suffering this bug in the latest Hugo version:

hugo v0.83.1-5AFE0A57+extended linux/amd64 BuildDate=2021-05-02T14:38:05Z VendorInfo=gohugoio

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[jmooring]

Still reproducible with v0.100.1

MRE

git clone --single-branch -b hugo-github-issue-7686 https://github.com/jmooring/hugo-testing hugo-github-issue-7686
cd hugo-github-issue-7686
hugo server

[jmooring]

@satotake This is still failing with 281554e. Is that expected?

git clone --single-branch -b hugo-github-issue-7686 https://github.com/jmooring/hugo-testing hugo-github-issue-7686
cd hugo-github-issue-7686
hugo server

[satotake]

My motivation of 281554e was from my own situation and I have never seen this issue. Not sure whether expected or not at the moment.
Anyway I will take a look at this tomorrow. @jmooring

[bep]

@jmooring have you tested it with ... Hugo 0.104.0?

[jmooring]

have you tested it with ... Hugo 0.104.0?

Yes, still fails.

[bep]

Yes, still fails.

That is certainly odd, oh well.

What I wish for my next life is that every OS implemented a file system with forward slashes and filenames limited to lower case ascii.

[satotake]

#10305 did not consider case-unmatched patterns.
So I had no expectation of {{ with resources.GetMatch "images/abc/*" }} for assets/images/ABC/kitten.jpg (though I have found that we should cover the case now.)

However, it is unexpected that {{ with resources.GetMatch "images/ABC/*" }} does not match the image.

Seemingly, we need more test and fixations.
Thanks for pointing out, @jmooring

[kc0bfv]

I wish for operating system APIs that handle path components more like objects than strings, and for all APIs to just automatically do the right thing for UTF8, and that every programmer wonders every time they touch a string, "will this work for UTF8?" But I have screwed it up myself plenty of times so I know that's a pipe dream.

…

On Fri, Sep 23, 2022, 11:12 Bjørn Erik Pedersen ***@***.***> wrote: Yes, still fails. That is certainly odd, oh well. What I wish for my next life is that very OS implemented a file system with forward slashes and filenames limited to lower case ascii. — Reply to this email directly, view it on GitHub <#7686 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALGLJIMKDBGHFIEPCEJQKDV7XJF3ANCNFSM4RLJMUGQ> . You are receiving this because you commented.Message ID: ***@***.***>