Get Location of Scrivener Project during Compile Processing

I have a writing project that I am wanting to compile to Plain Text and then perform post-processing on the command line.

The script that I want to run to do the processing is in a known location relative to the original Scrivener Project that I am compiling; however, the directory that holds both of them may not actually be in the same place between different systems. (This Scrivener project is in a git repository for reasons I don’t wish to litigate, and the processing script is a custom one that I wrote for my particular purposes) The export location is also different relative to that script.

As near as I can tell, I can get the location of the export folder, and the name of the text file I want to process in the export…but I can’t find a way to get the location of the actual Scrivener Project that I’m compiling! It does not appear to be in the environment for the shell, and I’m not sure if there are any other metavariables I could use in Scrivener.

Is there a mechanism inside of the Processing step of a Compile on a Plain Text compilation where I can get this information, so that I can therefore find the script I want to use for processing? If so, what is that mechanism? If not, is there another way I can go about solving this problem?

At the link is my workflow for solving a similar problem (among other things). Compiling external images requires different pathnames on Windows and the Mac. It doesn’t ask for information at compile time, but I only need to click and unclick a couple of checkboxes on each platform … or use platform-specific compile formats.

This is an interesting way of solving it! However, it still relies on hardcoded paths that you’re switching between. I would rather not assume that my projects sit in the same place on my hard drive all the time—it’s pretty common for me to get into a reorganizing mood, and I’ll put folders in all sorts of different places, and I don’t like the idea of having to re-do all of my compile settings across different projects to account for that. I’d rather just be able to say “the script to run to process this after the fact is at ../scripts/perform_processing.bash relative to the Scrivener project.”

Given that I’m using git, I might be able to do something with git rev-parse --show-toplevel to get a stable folder, and then work from there. I’d still rather do it within Scrivener itself.

If you put folders “all sorts of different places”, I don’t think I’d call it “organizing”. Different strokes for different folks, of course.

I think you misunderstand me.

Right now, for instance, I might have my current set of projects (both Scrivener and non) in ~/Workbench/Project1, ~/Workbench/Project2, and ~/Workbench/Project3. Then in six months when I realize that I don’t want all those projects in one place and want to break it up, it might become ~/Workbench/Novels/Project1, ~/Workbench/Games/Project2, and ~/Workbench/Novels/Project3. Then six months later, I finish Project1, so it moves to ~/Archive/Fiction/Novels/Project1. I still want to be able to do a compile if I need to even if it’s in the archive.

My organizational scheme adapts to what I’m working on, and that means things move around from time to time.

In short, over the course of a project’s lifetime from inception to work to hiatus to work to completion to a decade later, the folder in which it’s contained might itself live in a half-dozen different locations.

Anyways, that’s tangential to my point, which is that during that compile processing I’d like to have access to the Scrivener project location so that I can build appropriate paths relative to it, because I do not actually know where that project location will be in five years, so don’t want to include any hardcoded locations.

That said, if you must do that sort of thing in Scrivener, you could find a way to get a script to edit Replacements in compile.xml, which is hidden inside the project. Here they are :


[attachment=1]package contents.jpg[/attachment]

This is your friendly Moderator just popping into say that both storing a Scrivener project in a git repository and editing any part of the project with tools other than Scrivener are unsupported and entirely at your own risk.

It sounds like you know what you’re doing; the warning is mostly for other readers whose ambitions may exceed their abilities.


Could you use symbolic links to be able to have a common set of compile paths that are always good, but that repoint the necessary directories between the archive and workbench?

I could figure it out, eventually, but my laziness exceeds my ambitions.

I suspect that could work. It requires recreating the links when the OP wants to reorganize, but it wouldn’t be as onerous as modifying replacements in all his projects.


Strong agree! And I’d much rather not script to change the project.

I’m not entirely sure I understand what you mean. Each of my different writing projects has a different bespoke script for processing it as text (because of differences in structure, desired output, etc.). So I don’t want those centralized somewhere.

Alternatively, are you suggesting possibly that I just keep everything in the archive canonically, and create symbolic links in my Workbench? Hm, that’s an interesting idea, though I’ve also re-organized my archive once or twice in the last five years :sweatdrop:

It is sounding like I only have absolute paths at my disposal here, alas. Should I create a new topic in the Feature Request forum to request getting that “location of the Scrivener project” information added somehow?

You’d create a link on the hard disk, call it “where-stuff-is” or whatever, pointing to the root of your reorganized files (or any part of it). Whenever you need a pathname in that structure, start that path at the link, not at the actual location. If you reorganize things, just remove and recreate the link accordingly.