Is there a way to compile my project so that each chapter post-compilation is its own file?
I have a folder called test which contains a series of files, named 001.md, 002.md, 003.md etc.
So there has to be a way of doing this.
There’s a Unix utility called csplit so one way is to compile to text in Scrivener, change the extension to .md and then use csplit.
But I don’t think that’s how I generated the test folder.
Have a look at the solution posted in this thread. That in particular will take the additional step of post-processing the .md files into LaTeX files. So if all you want is the .md files, you would edit the script to remove the post-processing parts. It should be fairly straight-forward, but let me know if you run into any issues.
Thanks, but I’m pretty sure I didn’t use Ruby to split the files. I have a Scrivener license for Mac and Windows and another for iOS. I have Ruby installed only on Linux but there’s no native Scrivener option for Linux; so it’s unlikely I would have used it there. My pre-edit experiment split files are on Linux so my guess is that I used csplit but I don’t remember doing that either. 
What is the command line to execute your *rb script?
Ruby is always installed on a Mac, so you don’t have to worry about it there. As for Linux, yeah I haven’t really looked into automating Scrivener too much yet, in part because I suspect if it isn’t fully running within the WINE environment, it won’t work. But I don’t know. Once I get to the point where I get tired of running scripts by hand after compiling, I’ll look into it. 
As someone that always has four or five shell windows open, the Processing pane was always more nice than necessary, for me.
Ruby aside, if you’re more comfortable with another language or tool, like csplit, the core idea that is illustrated in that project does not depend upon Ruby. Using a unique divider system as a Section Layout, and then setting up your post-processing script to make use of that divider, is all you need to get a good result.
What is the command line to execute your *rb script?
It’s set up to simply take the input file as the single argument, which Scrivener passes to an embedded script by default, hence the lack of settings in the Processing compile format pane. So to execute manually on a compiled .md file that is ready to split:
$ /path/to/script/splitter.rb compiledOutput.md
Thank you. Forum requests 20 characters so “thank you” is insufficient.
I just found another way to do this.
File=>Export=> Files brings up a dialog which lets you accomplish this.
Under “Options” make sure that “do not export subdocuments” is NOT checked.
Sure, that works if you do not have any need for all of the zillion other things the compiler does, like evaluating placeholders, building out heading structures, combining small sections into larger “files”, etc. For me this export approach would never work. I don’t know what I’d do with 3,500 .md files, many as short as one paragraph. 
But if you’ve got 99% of what you need in the text editor itself, and each chunk of text in the binder maps directly to what you want a text file to be on the disk, then great!
I guess then this is an additional usage scenario for Scrivener. Write your book in Scrivener, export as .md files (even short ones, in my current project there are short files introducing and explaining what comes next), then add these .md files to the contents structure you’ve created using mdbook (GitHub - rust-lang/mdBook: Create book from markdown files. Like Gitbook but implemented in Rust)–it’s easy, just copy the directory-- upload the mdbook directory to a website and you have easily accessible html documentation to share with a group that’s much more responsive than an ePub or pdf, and because there are so many small files, updating is a matter of changing just a few files and not recompiling.
One problem with this scenario is that it is not easy to use Scrivener as an editor (that is, an engine that produces plain text). I’m using it more as a scrapbook and fighting continually with artifacts brought over while importing pdf, Word and other files. Even if the style is 12 point Courier, it’s not text: it’s rtf which just happens to display the Courier font at 12 points. As you know–but perhaps not everyone reading this thread does–there is a big difference. Rich text is not plain text at all. This means that I might have to convert some or all of those .md files through Pandoc or find a CLI way to convert them all to text.
Yeah, I’ve actually been looking into the MkDocs system as a way of providing an online version of Scrivener’s user manual. However I would still be looking to use the compiler as a means of putting together the material that ends up in the .md files it uses.
I don’t think one would need to sacrifice all of the fantastic things the compiler can do for you, to go down that route, in other words. But you could, as a choice, and would have to be very conscious of which types of technology to avoid when doing so (no footnotes, no styles, no embedded images, no Replacement-dependent stuff, no placeholders, etc.). For me, to sacrifice that stuff—especially in the user manual project—would mean a massive step backward, to a point where I’d question whether using Scrivener as the platform was the best move. That isn’t going to be the same metric for every project though, of course.
One problem with this scenario is that it is not easy to use Scrivener as an editor (that is, an engine that produces plain text). I’m using it more as a scrapbook and fighting continually with artifacts brought over while importing pdf, Word and other files.
I’d love a plain-text mode in some ways, or even just a less freeform text editor if that’s what it took. The arguments for not having a TXT mode are very good—a lot of what I just said above in fact are reasons for that. Without it you’d have to sacrifice a lot of Markdown-generating time savers (like footnotes), and even worse if you did use them and then “turn on” TXT mode you’d find highlights, styles, inline annotations and lots of other really useful capabilities permanently blown away. So that’s why I wonder if a less free-form editor is a better way forward for Scrivener. If changing the font isn’t a thing, for example, unless you have a really good reason to—and then that reason is stipulated through styles, not haphazard “junk” from webpages and PDF files, or whimsical font selectors on a toolbar a la word processor-centric writing approaches.
This means that I might have to convert some or all of those .md files through Pandoc or find a CLI way to convert them all to text.
Last but not least, this leads to another approach entirely, and that is one similar to how Marked works. For anyone not familiar, you can load a Scrivener project in this program and it will generate a live preview from the Markdown source—i.e. it’s a tool for authors composing with Markdown in the draft folder. It accomplishes this by knowing enough about the .scrivx XML schema to extract the binder titles and UUID codes for the Draft folder in order, and then hunting down the necessary RTF files in the Files/Data subfolders. It then uses the Mac’s conversion engine to dump the contents of those to TXT and concats the whole thing together with a depth-aware heading structure. I wouldn’t surprise me if it is also optimised to only rebuild the parts that change on the disk as you work too, rather than rebuilding the entire Draft folder with every auto-save event.
It’s a little more tricky than just doing that, as you have to weed out style markers, inline annotations and footnotes—but it’s another way in which one could conceivably generate content out of a Scrivener project. In Marked’s case, it dumps all of that into a tmp file. But another script could just as easily build a MkDocs site, and with some further awareness of Section Types, could even bridge the gap between “files” in the binder not meant to be sections—but outlined components of sections—with “files” in the binder that are meant to be gathering agents for those subsections, or what we would consider to be an actual section, or .md file, in a Gitbook/MkDocs/MDBook kind of system.
As for shell level conversion: check out textutils.