Handlebars::register_templates_directory doesn't handle trailing backslash in path correctly on Windows

[andrewhickman]

Minimal repo program:

fn main() {
    let path = std::env::args_os().nth(1).unwrap();
    let mut registry = handlebars::Handlebars::new();
    registry.register_templates_directory(".hbs", path).unwrap();
    println!("{:?}", registry);
}

Run against the following directory structure

test
└ test.hbs

With the path .\test\, outputs:

Handlebars { templates: {"est": Template { ...

Note the first letter of the filename has been lost.

[sunng87]

Thank you for reporting @andrewhickman. I will look into this later

[sunng87]

@andrewhickman since I don't have a window machine, could you please help me to verify if #389 fixed this?

[andrewhickman]

Yep, that's fixed it, thanks!

[nathan-osman]

I'm still seeing this with 3.5.1 on Windows 10 (20H2) :

let mut tpl = Handlebars::new();
tpl.register_templates_directory(".hbs", "templates/")
    .expect("unable to register templates");

println!("Templates:");
for (name, _) in &*tpl.get_templates() {
    println!(" - {}", name);
}

Assuming I have the following directory tree:

templates
  ├── index.hbs
  └── about.hbs

...the code prints:

Templates:
 - ndex
 - bout

[nathan-osman]

Peering through the source code, I found this:

handlebars-rust/src/registry.rs

Lines 247 to 251 in e703605

	let prefix_len = if dir_path.to_string_lossy().ends_with(path::MAIN_SEPARATOR) {
	dir_path.to_string_lossy().len()
	} else {
	dir_path.to_string_lossy().len() + 1
	};

Out of curiosity, why is prefix_len incremented by 1 if the native path separator isn't present? The function seems to exhibit the expected behavior if I replace it with the following line:

let prefix_len = dir_path.to_string_lossy().len();

[sunng87]

@nathan-osman this is to get the relative path of templates. We don't want the relative path to start with separator, so if given path doesn't end with it, we count it into prefix_len.

The issue seems to be you are using / on Windows, which is not the MAIN_SEPARATOR on Windows. I can fix this by checking either / or \.

[sunng87]

@nathan-osman 3.5.2 should fix this issue