being able to run a command with the compiled file as input

I wrote a book in Asciidoc (Asciidoctor) and used Scrivener as the editor (an enjoyable experience!). I had a toolchain, mainly Asciidoctor as the compiler, that each time converted the compiled plain text output from Scrivener to desired outputs (Docbook -> Latex -> PDF, HTML, …) and doing some other stuffs such as managing the citations and bibliographies. The problem was that with each compile I had to run my toolchain manually. Life would be easier if in the compile profile one can specify a command to be run after compilation and the command has a template style to be filled by Scrivener (most notably the output file name).

I guess this hopefully easy extension can ease the procedure for those who rely on toolchains to create their outputs.

PS: Probably I should write it in another post but to see Scrivener embracing Asciidoc would be a good news for me and probably lots of others.

The request to add custom command-line post-processing to the compile procedure has been turned down several times in the past. In the grand scheme of things that isn’t a huge negative however, as there already is a way to hook up scripting using the MultiMarkdown environment (which has an optional shell-script driven workflow that can be replaced with your own). This thread from a while back should shed a little light on the process.

The one thing you do have to be wary of (when using a tool-chain that doesn’t involve a Markdownalike) is the compiler inserting MultiMarkdown syntax for a few things: preserve formatting, footnotes, comments, inline annotations, headings (as generated via the Formatting pane) and images. However if you’ve been using Scrivener to compose stock DocBook plain-text, those are probably not things you make use of anyway.

Another approach, that doesn’t involve rewiring MMD, is a tool like Hazel or even just folder actions with AppleScript for free. I will sometimes use Hazel for post-compile processing, as you can set up a watch folder and have Hazel monitor it for incoming .tex (or whatever) files, execute scripts, move the results of the scripts to a central output folder, and clean up any messes created by the automation.

My other comment just wiped out …

Thanks Amber for clarification and suggestions.

The suggestion in your other post is somehow hacking Scrivener and usually I try to avoid them as with the next update that hidden feature might disappear or change.

Using things like Hazle is an option (although not my favorite one) but it only notifies of change in a file. If Scrivener could call a command then it could share more information about the document with the command. At the moment I have to use scrivener plus a configuration file for my toolchain that specifies which bibliographic file, which referencing style, which template, which meta-data, if it is RTL, which … . It would be much easier to have Scrivener as the only command or configuration center and do every thing from there. Also it helps to add seamless connection with arbitrary writing protocols (such as Asciidoc for me) or arbitrary toolchains (such as mine).

That is a good thing to be mindful of, however the way this is developed is designed with upgrading in mind. Scrivener merely looks for the presence of the shell script and if found, executes that script, piping the compiled data to it. Since the script is in your ~/Library/Application Support folder, it isn’t touched by updates to Scrivener.

And if you mean concern over whether we’ll remove the feature, I can’t promise anything forever of course, but this side of Scrivener has been there since day one and is only going to get more sophisticated in the future. This specific method I’ve described will be a part of the next iteration of Scrivener as well, which if it lasts as long as this one, is probably long enough to suit you for several major projects.

I’m curious – this seems like a reasonable toolchain-neutral hook to include. Would you be willing to discuss why this would be turned down?

Thanks Amber, I will try it.

I don’t know how the requirement management processes work in Scrivener, but keep my one vote for extensiblity features (not bonded to multi-markdown) specially for those who prefer other writing protocols or toolchains. I wrote this book (actually dissertation) (used to write O’Reilly books) and I think that with enough extensibility features Scrivener can be extended to give those features almost easily.

You’d have to ask Keith on that. I don’t recall the answer well enough to do justice to it, but the basic gist as I recall was that having exposed command-line options in the compile GUI would present too much complexity to everyone, for something advanced users can already accomplish with the external script calls. I.e. someone with the wherewithal to automate a sequence of processes at the shell level shouldn’t need a GUI answer to the problem.

I haven’t played with the feature in question, but from what you stated previously in the thread it sounds like this script call is tied into the Markdown support. I can see plenty of situations where I’d want to take advantage of a post-compile script without having to mess with Markdown. Something simple like a checkbox to use/not use Markdown and being able to change the name of the script that Scrivener was looking for.

Clearly, I need to get off my butt, buy a Scrivener license for my Mac, and start playing around.

Only formally. Yes, if you use Scrivener features that are converted to MultiMarkdown on compile (such as inline images or footnotes), then you will encounter MMD syntax injected into the output. But if you avoid that stuff, as you would have to anyway, then the output is just good old UTF–8 text to a script, STDIN/STDOUT the compile data and there you go, a post-processing workflow. Not fancy by any means, but it works.

On a Mac you can also swap out MMD itself. It installs to /usr/local/bin/multimarkdown, which the compiler checks for first, before falling back to the built-in copy. I might have mentioned that method in one of the links, but if you put your script there then you don’t even need the special checkbox. I use the XSLT work-around myself since I otherwise do want MMD installed normally. If you never use MMD, that’s an empty shell call waiting to be used.

I do suppose plain-text is the unspoken limitation here. You aren’t going to get PDF data piped through the shell in any fashion, not that most people would have a reason to do that—but I once did in fact write a Perl script that built PDF files out of entries in a database, so I suppose it isn’t entirely inconceivable. :slight_smile:

That’s what I’m referring as having been described as too much for the GUI side. You’ll notice the way I’m phrasing that. :slight_smile: Personally speaking, the more commands the merrier, but if I was the one doing all of the design on the compiler it wouldn’t have any rich text features because I consider all of that stuff a needlessly complicated way to write! :smiling_imp:

Important Note: the stuff I’m talking about isn’t really relevant to the Mac App Store version. Sandboxing doesn’t allow for these kinds of neat tricks so much. And all of the external MMD wiring will be removed in a future update. The direct-sale version, which we maintain creative control over, will of course continue to have these features.