CODEWITHSUNDEEP
pythonpython-3.xsubprocesspandoc
somenxavier
somenxavier

Reputation: 1579

subprocess.run does run properly pandoc

If you run pandoc directly with minimal example no problem:

$ cat workfile.md 
This is a **test** see ![alt text](https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png)
$ pandoc workfile.md 
<p>This is a <strong>test</strong> see <img src="https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png" alt="alt text" /></p>

But if you call it via subprocess.run, then it fails. This minimal example:

import subprocess, os

path = 'workfile.md'
contents = "This is a **test** see ![alt text](https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png)"

with open(path, 'w') as f:

    f.write(contents)
    pbody = subprocess.run(["pandoc", "{}".format(path)], check=True, stdout=subprocess.PIPE)
    print("**** pbody: ", pbody)

gives us 

**** pbody:  CompletedProcess(args=['pandoc', 'workfile.md'], returncode=0, stdout=b'\n')

Upvotes: 0

Views: 136

Answers (1)

Henry Finucane
Henry Finucane

Reputation: 714

One of the things that Python (and all other programming languages) do to increase performance of common operations is to maintain a buffer for things like file printing. Depending on how much you write to a file, not all of it will get written immediately, which lets the language reduce the amount of (slow) operations it has to do to actually get things on the disk. If you call f.flush() after f.write(contents), you should see pandoc pick up the actual contents of the file.

There's a further layer of buffering that's also worth noting- your operating system may have an updated version of the file in memory, but may not have actually written it to disk. If you're writing a server, you may also want to call os.fsync, which will force the OS to write it to disk.

Upvotes: 1

Related Questions