Open rhyst opened 4 years ago
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
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
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.
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
@satotake This is still failing with https://github.com/gohugoio/hugo/commit/281554ee97eb243af097611aaf6bfec8940ad6d1. 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
My motivation of https://github.com/gohugoio/hugo/commit/281554ee97eb243af097611aaf6bfec8940ad6d1 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
@jmooring have you tested it with ... Hugo 0.104.0?
have you tested it with ... Hugo 0.104.0?
Yes, still fails.
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.
https://github.com/gohugoio/hugo/pull/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
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 https://github.com/gohugoio/hugo/issues/7686#issuecomment-1256404720, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALGLJIMKDBGHFIEPCEJQKDV7XJF3ANCNFSM4RLJMUGQ . You are receiving this because you commented.Message ID: @.***>
What version of Hugo are you using (
hugo version
)?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.