MobileRead Forums - View Single Post - Path separator not working in CC templates?

DavidTC · 08-28-2016, 07:41 PM

Calibre removes slashes in template items, with the exception of a leading slash in a tag.

I've been testing this since you posted, and I am in shock.

The behavior I was expecting, in fact, the behavior that I bet everyone was suspecting, that when you fill in a template, that template should come up with the same result everywhere. And then, *at the end*, if it's saving a file, it parse the directories and, at the end, right before it saves, it replaces invalid characters.

And I think most of us assume that if the result of the template evaluation is A/B, it would treat that the same if it got that from {#ab} or {#a}/{#b} or some program.

But apparently getting a metadata field, either with {} or field(), has some magical string processing during it that behaves differently if you're calculating a save template, and only a save template.

Not only is this an extremely inconsistent thing, it sorta breaks the entire concept of the language, if completely identical pieces of code can give different results depending on where they are.

It also appears to not be documented anywhere. The documentation says, literally, 'field(name) – returns the metadata field named by name.', This documentation is wrong.

Instead, what field() does is 'returns the metadata field named be name, unless it's called inside a save template, at which point it munges the metadata field to be more like a file name before returning it.' And that's just field(), there's probably others non-documented...how does lookup() behave? Does this affect first_non_empty()? author_links()?

Also, does raw_field() get the value *without* doing that? I probably should check, but I don't have the time, and having to constantly restart Calibre to change the save template is annoying. (Which is why I put that in a field in the first place.) Is there even a *way* to get the original field?

Seriously, the solution to 'newbies might have a / in their tags and accidentally make directories' was to change how some part of the language worked in a certain place. (And then not mention it anywhere.) Instead of just adding a strip_nonfile_chars() function and mentioning people should use {#fieldname:strip_nonfile_chars()} in the intro template documentation if that happens?

And at this point...yes, I know some people probably have existing stuff that assumes it, and oh noes, it can't ever be changed....but wow, this is such a huge and weird behavioral inconsistency that I argue it really should be dealt with. Give people a checkbox on the save template screen if they want the old way.

But that's not really you, I need to talk to kovidgoyal about that, I guess?

08-28-2016, 07:41 PM	#4
DavidTC Connoisseur Posts: 77 Karma: 10 Join Date: Sep 2011 Device: Nook, Boox C67ML	Calibre removes slashes in template items, with the exception of a leading slash in a tag. I've been testing this since you posted, and I am in shock. The behavior I was expecting, in fact, the behavior that I bet everyone was suspecting, that when you fill in a template, that template should come up with the same result everywhere. And then, at the end, if it's saving a file, it parse the directories and, at the end, right before it saves, it replaces invalid characters. And I think most of us assume that if the result of the template evaluation is A/B, it would treat that the same if it got that from {#ab} or {#a}/{#b} or some program. But apparently getting a metadata field, either with {} or field(), has some magical string processing during it that behaves differently if you're calculating a save template, and only a save template. Not only is this an extremely inconsistent thing, it sorta breaks the entire concept of the language, if completely identical pieces of code can give different results depending on where they are. It also appears to not be documented anywhere. The documentation says, literally, 'field(name) – returns the metadata field named by name.', This documentation is wrong. Instead, what field() does is 'returns the metadata field named be name, unless it's called inside a save template, at which point it munges the metadata field to be more like a file name before returning it.' And that's just field(), there's probably others non-documented...how does lookup() behave? Does this affect first_non_empty()? author_links()? Also, does raw_field() get the value without doing that? I probably should check, but I don't have the time, and having to constantly restart Calibre to change the save template is annoying. (Which is why I put that in a field in the first place.) Is there even a way to get the original field? Seriously, the solution to 'newbies might have a / in their tags and accidentally make directories' was to change how some part of the language worked in a certain place. (And then not mention it anywhere.) Instead of just adding a strip_nonfile_chars() function and mentioning people should use {#fieldname:strip_nonfile_chars()} in the intro template documentation if that happens? And at this point...yes, I know some people probably have existing stuff that assumes it, and oh noes, it can't ever be changed....but wow, this is such a huge and weird behavioral inconsistency that I argue it really should be dealt with. Give people a checkbox on the save template screen if they want the old way. But that's not really you, I need to talk to kovidgoyal about that, I guess?