Post-process on command line not working as §24.22.1 leads me to expect

What I expected:

  1. However, <$inputfile> is being set to the file I specify in the Export dialog, and that is the file where the pandoc output is being sent, not a temporary location. So if I use the destination suffix in the Export dialog (eg, .docx), then <$inputfile> and <$outputname>.docx are the same. That my <$outputname>.docx is being understood is shown by the list of applications to open in in the Export dialog (and the output file is opened even though the Export dialog has another suffix).

  2. The environment variables I put in the Environment field (in name=value form) are not being added to the environment but are being prepended to PATH, giving, eg, “PATH=Test2=fine:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin” (I’m calling a shell script that calls env).

I use a save file name that is recognisable as an markdown file, not the name of a final file after the post-processing has finished. So e.g. I compile to MMD and save to ~/Desktop/test/ — the post-processing system changes directory to ~/Desktop/test/ and <$inputfile> is set to and <$outputname> is set to test — your description in (1) makes sense in that you save to test.docx (which is not a docx file but a markdown file actually), therefore <$inputfile> is test.docx and <$outputname> is test which you append with .docx to make test.docx. This all seems to make sense to me…

(2) this is IMO a mistake in the user manual (or possibly a feature that will come in an update?). Environment currently only refers to the PATH and should just be a colon separated PATH list. I can confirm using scrivomatic that if you put PATH=/my/path then you get the wrong output (PATH= should not go into the Final ENV PATH which it does).

I think i agree that the manual is misleading, at least from the perspective a post-processing script. As far as i can tell, the post-processing script is run in the target compile folder path, for a slow post-process I can actually see the <$inputfile> appear first with a log file (I redirect STDOUT and STDERR to a log file in the same directory), the log file is updated and the final outputfile is then generated. It does not seem this happens in a temporary folder, or if it does it is perfectly mirrored by the activity in the compile target folder…

Glad to know that there is not some bizarre problem with my installation.

I actually like what the manual suggests (or implies; it’s not completely clear). The filename you type in the Export dialog box should be the result. The current system has another oddity: you are asked before overwriting the intermediary file, whereas the <$outputname>.docx file is overwritten without question.

The current behaviour is correct and the manual is misleading - I’ll get Ioa to pick that up when he returns from his holiday in the New Year. There are certain limitations involved here because the Export panel knows nothing about the post-processing. Scrivener can’t know what post-processing will do - it can only generate the plain text file and then run the script on it.

All the best,

The manual is close to what most makes sense to me: the Export dialog gives the final output file, to which its namesake is moved if created in the temp directory, or which it is expected the post-processing will create directly (either would make sense). However, what we have is a huge step forward from Scrivener 2, and quite workable.

A handy tweak would be that if there is no <$outputname>.sfx in the arguments, the “Open compiled document in” drop-down list appears based on the suffix in the filename dialog box. I know that the post-processing can also do that, but it’s nice to have the control in the dialog box.

Obviously, the Environment label needs to change its name. Adding an Environment field as per the manual could also be useful.