Pandoc: Pandoc refuses to write docx/odt to stdout

[marcelklehr]

Hey,

first up, thanks for this amazing tool!

Now, to my issue: I'd like to use pandoc as an import/export backend in a web application. Is there a reason why pandoc refuses to write docx/odt to stdout. It would be very nice to use the stdout to obtain the result of the conversion, since I'd have to deal with temporary files otherwise.

[jgm]

On a *nix system you should be able to do:

pandoc -t docx -o /dev/stdout

Does this not work?

I'm open to changing this -- really it was just to avoid
getting lots of complaints from users who don't know what
they're doing. But since the above works, maybe it's not
necessary.

+++ Marcel Klehr [Jan 24 16 07:08 ]:

Hey,

first up, thanks for this amazing tool!

Now, to my issue: I'd like to use pandoc as an import/export backend in
a web application. Is there a reason why pandoc refuses to write
docx/odt to stdout. It would be very nice to use the stdout to obtain
the result of the conversion, since I'd have to deal with temporary
files otherwise.

—
Reply to this email directly or [1]view it on GitHub.

References

1. https://github.com/jgm/pandoc/issues/2677

[adius]

@jgm But why can pandoc not write pdf, odt, … to stdout like the other formats?

[jgm]

@adius Of course, I could easily change pandoc so that binary formats, too, write to stdout if you don't specify an output file. The reason I didn't design it that way originally is that I wanted to avoid users having the experience of doing pandoc myfile.txt -t pdf and then complaining that pandoc spit out a bunch of weird characters and froze up their terminal. I'm not sure how much this would happen, but that was my thinking.

[marcelklehr]

Perhaps a solution would be to introduce a flag like --force or something like that, so new users are saved but users who know what they're doing can opt in?

Update: Mh. I was under the impression we had discussed this already. I guess I didn't respond to the right mail to make github show my comments... :/

[jgm]

I don't see a big difference between making people do
pandoc --force and making them do pandoc -o /dev/stdout
(which they can already do).

+++ Marcel Klehr [Apr 11 16 12:33 ]:

Perhaps a solution would be to introduce a flag like --force or
something like that, so new users are saved but users who know what
they're doing can opt in?

—
You are receiving this because you were mentioned.
Reply to this email directly or [1]view it on GitHub

References

1. https://github.com/jgm/pandoc/issues/2677#issuecomment-208518899

[adius]

@jgm How about simply checking if it is printed to the terminal or piped to another command/file.
When it's printed to terminal a warning could be printed instead.
E.g. in nodejs this can be achieved fairly easy:

$ node -p -e "Boolean(process.stdout.isTTY)"
true
$ node -p -e "Boolean(process.stdout.isTTY)" | cat
false

[jgm]

[1]@jgm How about simply checking if it is printed to the terminal or
piped to another command/file.
When it's printed to terminal a warning could be printed instead.

It's a nice idea, but the only Haskell solution I can
currently find seems to not work under Windows:

https://rosettacode.org/wiki/Check_output_device_is_a_terminal#Haskell

(This uses http://hackage.haskell.org/package/unix-2.7.1.0)

[marcelklehr]

pandoc -o /dev/stdout doesn't work under windows either, though.

[jgm]

Yes, I suppose on Windows we could just have it behave
as it does currently.

+++ Marcel Klehr [Apr 11 16 14:09 ]:

pandoc -o /dev/stdout doesn't work under windows either, though.

—
You are receiving this because you were mentioned.
Reply to this email directly or [1]view it on GitHub

References

1. https://github.com/jgm/pandoc/issues/2677#issuecomment-208561764

[jankatins]

This seems to work under windows, at least it spits out a lot of binary stuff

echo # hello | pandoc -t docx -o CON

Although I haven't found a way to redirect that output to a file again on the command line and I'm not sure if the parent process could catch it (e.g. a python subprocess).

[lifan0127]

I am facing this issue with regard to the parent process not catching the output via -o /dev/stdout in NodeJS:

const proc = spawn(command, ['-f', 'markdown', '-t', 'docx', '-o', '/dev/stdout'])
proc.stdout.on('data', chunk => {
    console.log(chunk.toString())  // No output
})

This seems to work under windows, at least it spits out a lot of binary stuff

echo # hello | pandoc -t docx -o CON

Although I haven't found a way to redirect that output to a file again on the command line and I'm not sure if the parent process could catch it (e.g. a python subprocess).

[dAnjou]

The proposed solution (-o /dev/stdout) doesn't work for PDFs.

I don't think it's worth it to keep this behaviour just to protect users, they chose to use a command line tool to convert documents, they will figure it out.

[mb21]

Actually, this has been implemented for a while now, as follows. From the MANUAL:

-o or --output: Write output to FILE instead of stdout. If FILE is -, output will go to stdout, even if a non-textual format (docx, odt, epub2, epub3) is specified.

Thus use:

pandoc -t docx -o -

[dAnjou]

$ pandoc --version
pandoc 2.7.3
Compiled with pandoc-types 1.17.5.4, texmath 0.11.2.2, skylighting 0.8.1
$ pandoc -t pdf README.md -o -
Unknown writer: pdf
To create a pdf using pandoc, use -t latex|beamer|context|ms|html5
and specify an output file with .pdf extension (-o filename.pdf).

I guess I could create a new issue for PDF but the underlying issue is the same, I think.

[agusmba]

I guess I could create a new issue for PDF but the underlying issue is the same, I think.

Not really, since it seems that PDF output is achieved by pandoc understanding the output file extension pdf, which you cannot provide if you want to use stdout. This is due to having different writers capable of generating PDF in the end.

[dAnjou]

Whether it's the output file extension or --to, it's both going to be pdf. Pandoc then uses a default writer (i.e. LaTeX), or you can specify another one with --pdf-engine.

Source: https://pandoc.org/MANUAL.html#creating-a-pdf

I don't think there's a technical reason that this is not possible.

[jgm]

It's certainly true that we could use a default writer, which might be modified depending on the choice of pdf-engine.

I think I designed it the way it is because, conceptually, there's a distinction between PDF output and all the others (including binary formats like docx or epub). In all the other cases, pandoc itself is creating the output. In the case of PDF, pandoc is just creating an intermediary, then using another program to create the PDF. But I'm open to the idea of making -t pdf work. It should be a separate issue though.