Hugo environment issues (filenames)

support
1

Issue 1

I have an odd issue when I last published a new Hugo based website.

@jmooring help me with that last time.

The problem was the Case Sensitive filename of an image file.


-![CE Logo](/svg/ce-logo.svg)

+![CE Logo](/svg/CE-logo.svg)

The problem is, that in Windows and macOS, this hasn’t made any difference (and I think it shall, but this system is not so strict on being case sensitive) and all builds working fine locally, then when tried to push to Netlify (or right now tried to run locally on Ubuntu) the build failing as file doesn’t exist as I am referring to file in small letters and for with capitals.

Issue 2

Now, I got another website when an issue is related.

Again, on windows and macOS working fine but on Netlify and Ubuntu failing.

The issue is below part in my shortcode


{{ $isJPG := eq (path.Ext $ftimgsrc) ".jpg" }}

but it is not an issue of the shortcode, is an issue of the environment.

In windows and macOS when I request to get an extension by path.Ext for file 03-2015-08-07-18.22.19.jpg I will get .jpg but in Linux environment is not that case and likely extension will be after the first occurrence of the dot.

For 03-2015-08-07-18.22.19.jpg will be likely .22.19.jpg

It will be nice if when running hugo serve to behave in the same manners in all systems (preferably in linux), so this will help in finding issues much quicker.

Similar with FILE.jpg and file.jpg to be treated separately, at least by Hugo. It’s like bypassing the environment, and not quite sure it’s even possible, but think it’s worth discussing.

Issue 3

Also, what I noticed is the issue with files with the following filename 20180319-070917-017-13-min.jpg

Example


"/featuredImages/2018/03/20180319-070917-017-13-min.jpg"

the file exists and there is nothing wrong with it, but for some reason causing the failure of shortcodes.

If I will rename this file to something else (doesn’t matter what), that doesn’t start with YYYYMMDD it will work well without failure.

There may be a case where, if filename is in format YYYYMMDD-HHMMSS etc. Hugo is modifying a path for that.

Unable to confirm, as failure doesn’t show too many details and I renamed all problematic files.

Issue 4

Also, this happening as well #7686

/featuredImages/2019/05/Lot_balonem_Garnki-Kosciernica_24-05-2019-113-min.jpg

File exist in /featuredImages/2019/05/

-rw-r--r--@ 1 dariusz  staff  362131  7 Dec 22:50 Lot_balonem_Garnki-Kosciernica_24-05-2019-113-min.jpg
-rw-r--r--  1 dariusz  staff  180194  8 Dec 13:13 Lot_balonem_Garnki-Kosciernica_24-05-2019-113-min.webp

but as I noticed, this file is landing in /featuredimages/ folder not /featuredImages/ (look on capital letter in patch)

when I rename this file to something else, it lands in right folder.

ps. there is no /featuredimage/ folder or any file refering to it with letter i not been in caps.

Quite a bit of issue and worth splitting this into 2 or 3 issues?

Please advise if worth raising an issue on GitHub?

2

Issue 1:

That there is right. Windows for instance does not care about that, so GoHugo can’t care. It has to take what Windows gives. Not sure about the same issue under a Unix based system (like Mac or Linux), that one should be able to work through that.

The trick here is some hack-around like lowercasing all filenames in the layout files. This way you can be sure what you get. This does not solve any issue with people who like to have a logo.jpg and Logo.jpg in the same layout, but honestly… meh :wink:

Issue 2:

I am on Ubunutu and never had that issue. Interesting. According to the documentation it is supposed to return the part after the final dot. Might be a bug.

Issue 3:

Blackbox. I would say it’s not at that path, because the / means site root and you might not be where you think you are. This explanation might confuse, but it’s what you get with this much (or not much) information. Most cases with “that image exist but Hugo thinks it’s not existing” are path related. Post a sample directory layout (where is the image) and a layout file (what does Hugo do with the image).

Issue 4:

You opened an issue on Github it seems, so I will ignore that one.

For the future:

If you have 4 Problems then either open a thread with the first one, then solve it and open the next one or just open 4 threads. Some of these belong together, but not all I think and it will become chaotic once some people answer single issues instead of all of them.

PS: Sidebar… I stopped using special characters in filenames and upper/lower cases back in the last century. It takes hard work to consequently work that way, but the reward of not having to work through these kind of issues is very gratifying. Seriously, not joking here. Same with spaces in filenames. Think about all the different kind of webservers you might run into in the end.

3

Issue 1: Correct behavior. Please don’t log a bug.

Issue 2: Not reproducible. Please don’t log a bug. Tested on Ubuntu and Windows.

{{ "01-2015-06-07-19.40.00.jpg" | path.Ext }} --> .jpg

Issue 3: Not reproducible. Please don’t log a bug.

The majority of web sites (> 60%) are known to be served by Apache or NGINX – both are case sensitive by default.

The majority (some estimates are as high as 95%) of web servers are running on Linux – a case sensitive operating system.

:+1: :+1: :+1:

4

Issue 1.

Thanks for the feedback.

Issue 2.

Yes, It may be a coincidence in my environment. Tried to replicate it and have not been able to, hence will leave it.

Issue 3

Please ignore it, it relates to the wrong patch in Issue 4.

Issue 4

The issue on GitHub ( #7686) is not mine but thought it was related, but in the end, I found where it was.

I had some files in content directory referred to /featuredImage/ and others /featuredimage/ (one capital letter difference).

In the Linux environment, these are two different folders.

I sync Git a couple of times and didn’t notice that on the Git end it create two folders. Some content files have been put in 1st folder, others in 2nd, this is why it failed (didn’t fail in a non-case sensitive environment as both folders are merged in one).

I correct an inconsistency in markdown files in relation to Uppercase and Lowercase but (see issue 1) for my system it was no difference, hence no changes have been synced (pushed) as for macOS (Windows) both folders are still 1 folder.

I changed filenames for files and that action put them in the right folder. When I did that I realised that will be easier to just delete the repo and push files to the new one. Learned a lot on that issue. It’s still annoying, but not Hugo fault that some operating systems are case sensitive and others not.

Even spoke with Apple Support and they do not recommend reinstalling the system (despite its possibe) with case sensitive (know why, as less technical people will get confused).

Ideally will be to have Hugo working with case sensitive, but that’s not possible when the environment is not.

Will knew for future where to look.

Turning on the virtual Ubuntu environment and pulling git helped a lot and think will use that in future for evaluation.

Thank you all for the feedback.