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

aj
ajbuch
Posts: 15
Joined: Sun Aug 12, 2012 8:13 am
Platform: Mac

Tue Dec 19, 2017 10:31 am Post

What I expected:
it will no longer produce a Markdown text file where you choose to compile. Instead that file will be held in a hidden temporary location, to be further processed by the command you specify in the fields below. The file that is created by those commands will be picked up by Scrivener automatically and placed into the designated compile folder at the conclusion of processing.


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).

User avatar
nontroppo
Posts: 868
Joined: Mon Mar 05, 2007 5:22 pm
Platform: Mac
Location: Airstrip One

Tue Dec 19, 2017 11:52 am Post

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/test.md — the post-processing system changes directory to ~/Desktop/test/ and <$inputfile> is set to test.md 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).

=== Scrivomatic V1.0.11 Report @ 2017-12-19 19:29:49 +0800 ===
Working directory: /Users/ian/Desktop/test.md
...
====== Final ENV PATH: ======
/Users/ian/.rbenv/shims:/Library/TeX/texbin:/Users/ian/bin:/usr/local/bin:PATH=/Users/ian/Code:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin



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...

aj
ajbuch
Posts: 15
Joined: Sun Aug 12, 2012 8:13 am
Platform: Mac

Tue Dec 19, 2017 1:02 pm Post

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.

User avatar
KB
Site Admin
Posts: 19299
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Wed Dec 20, 2017 5:29 pm Post

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,
Keith
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

aj
ajbuch
Posts: 15
Joined: Sun Aug 12, 2012 8:13 am
Platform: Mac

Thu Dec 21, 2017 1:46 am Post

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.