Template cannot be set using a Bash process substitution

[sersorrel]

Pandoc appears to silently append an extension to the template name if it feels like it, which means that you can't use a file which doesn't have the "correct" extension as a template:

$ pandoc /dev/null -o /dev/null --template <(echo)
pandoc: /dev/fd/63.markdown: openBinaryFile: does not exist (No such file or directory)

Pandoc version: 2.3.1, reproduced on 2.6 (though then the extension added is html, not markdown)

[jgm]

See the manual for `--template`:

If no extension is specified, an extension corresponding to the writer will be added, so that `--template=special` looks for `special.html` for HTML output.

The point of this is to allow you to do --template=letter or --template=default and have the right template for the format be used. I'm sure there are ways to work around this for your purposes. Or you may have a concrete suggestion as to how pandoc could be changed without throwing away the above feature. Otherwise, this should be closed.

[sersorrel]

Or you may have a concrete suggestion as to
how pandoc could be changed without throwing away the
above feature.

Could it check to see if the bare filename-as-given, with no extension, exists, and use it if it does? (if it doesn't, then fall back to the current behaviour)

[jgm]

That seems like a reasonable solution, though it would require a change to documented behavior.

[jraygauthier]

Could it use the path as is when an absolute path is provided and keep the current behavior when a basename is provided?

[jgm]

Also a reasonable solution. But of course it may break things for people who are doing --template /path/to/my and letting the appropriate extension be added depending on the output format...

I suppose a very narrow fix would be to special-case absolute filenames beginning with /dev/fd...

[jraygauthier]

break things for people who are doing --template /path/to/my

Yes you are right.

special-case absolute filenames beginning with /dev/fd

That seems brittle tough.

A couple other potential solutions (suggested names, could be better):

• --template-full-path <(my-cmd) / --template-strict-full-path <(my-cmd)
• --template <(my-cmd) + --template-use-exact-path (a flag that alter the behavior of --template)

Or, potentially easier and better for shells that won't support process substitution:

• --template-str '$toc$'

This last option is not process substitution per say, but would allow for the same use case --template-str "$(my-cmd)" although with the downside of using more memory (not a big issue in my opinion as template are generally pretty small). It would additionally provide a nice one liner solution to #5675, not requiring messing with files.

[sersorrel]

these seem like very overcomplicated solutions. given the current behaviour of:

• look for $template.$ext
• if found, use it
• otherwise, crash

would it not be simpler to modify the behaviour to:

• look for $template.$ext
• if found, use it
• otherwise, look for $template
• if found, use it
• otherwise, crash

this seems backwards-compatible (unless someone is relying on the current behaviour of "exit if $template.$ext does not exist") to me.

[jgm]

I went for a slightly different approach: first look for the extensionless template, and fall back to adding the extension if it isn't found. This is slightly less backwards-compatible (but it's pretty unlikely that someone will use a template foo.markdown and just happen to have a file foo in the template search path). But it yields better error messages, since the failure occurs with the extension added.

Anyway, bash process substitutions now work.