Problem with windows paths in md hugo files (c:\users in is treated as \u unicode character sequence)

support
1

We have our documentation on a hugo instance and people can change it by committing markdown files to our repo. This is normally great but some people need to mention windows paths in their markdown files.

Examples:
I:\a_long\path\project\ui\something
C:\users\myname\mydirectory\

In both examples, the \u will be treated as a \u character sequence, hugo logs “Uncaught SyntaxError: malformed Unicode character escape sequence” into the browser console and the search is broken.

I have not found a way to make hugo happy. I tried \\ to escape the \, I tried \ \u005C and whatever I could think of but the problem persists. Telling the users to use a better operating system also didn’t work.

Does anyone have an idea how to overcome this issue or configure that we don’t want unicode sequences interpreted but rather want to print the text, regardless of \u or not? I think it is somehow related to the yaml parser that hugo uses but it should not be something unusual that people document windows paths with backslashes and \u should also not be uncommon. So I’m really surprised that I can’t find anything about this topic online.

2

This is (obviously) a JavaScript error, not a Hugo error.

  • Are these paths in the front matter, or in the body?
  • If front matter, which format (TOML, YAML, or JSON)?
  • Which theme?
  • Have you modified the theme?
  • Which search method/service?
  • How do you build the search index?
1 Like
3

Hi @jmooring , thank you for taking the time to answer my question.

I’m a n00b when it comes to hugo and I came to the project when all of this was already in existence. It’s still a bit hard to know which parts are customizations and which belong to hugo itself. I assume the theme is modified but I don’t know which theme was modified.

The paths are in the body. But when you mention the search indexing, I think this could be a good starting point. I had thought it would be something that belongs to vanilla hugo.

4

No.

With this front matter:

---
title: Post 1
date: 2024-01-09T07:15:59-08:00
path: c:\u\x
---

and this template:

<script>console.log({{ .Params.path }})</script>

Hugo escapes the backslashes when rendering:

<script>console.log("c:\\u\\x")</script>

We do the same thing when marshaling to JSON. This template:

{{ $map := dict "path" .Params.Path }}
{{ jsonify $map }}

is rendered to:

{
  "path": "c:\\u\\x"
}
5

Got it, I’m so stupid… Thanks for pointing me into the right direction. It was rather obvious, now that I think about it but that’s how it is.
The search indexing does a .toLowerCase() which fails on the \u character sequence.

“c:\something\users\blabla”.toLowerCase() → Uncaught SyntaxError: malformed Unicode character escape sequence

As you said, a javascript error, nothing to do with Hugo. Thanks again.

1 Like
6

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