10 comments

[ 3.1 ms ] story [ 25.6 ms ] thread
I didn’t read this in enough depth to figure out what it was talking about, but I did see this:

> Most distributions have the printf command

printf is part of SUS and POSIX; this means that pretty much every system from this millennium will have it.

Not only is it guaranteed by POSIX, it's also a built-in in bash. (And the author, I believe, is writing bash, not generic shell: the shebang in part 1 is to bash, and "local", which appears in this article, is not defined by POSIX.)

I suppose there could be an (early?) version of bash that it wasn't built it (and then the POSIX argument applies); but OS X ships a version of bash over a decade old (2007), and it's a builtin there, so it's been there for at least that long…

Interesting solution, but I would classify the first ~60% of post as yak shaving that has nothing to do with markdown and themes.

The script is maybe too complicated and could have been simplified enormously

This is cool, but a lot of it is about bash programming, and it also heavily ties you to PDF output. IMO no real Markdown based authoring workflow is workable without a preprocessor. I've used many, from GCC's to several home written ones, but I recently started porting my whole authoring workflow for technical documentation to PP (http://cdsoft.fr/pp). It gives you integrated diagrams with ditaa and several similar packages, and most importantly fills the gap that pandoc leaves wrt composing documents from fragments. Just treating all input files as one continuous input document just doesn't cut it for anything more than simple README's.

Either way, it's great to see how far text-based authoring workflows have come over the last 10 years. At some point Docbook had great promise but XSL is just too hard, and not even that powerful after you managed to grok it, so you still needed to cobble together a bunch of functionality on top of it.