Why?

I figured that if I had to open an editor and push content through a traditional CMS with file attachments, e.g. WordPress, I’d very quickly abandon writing anything, or at least never get around to publishing anything I’ve written. On top of the limitations of those systems is the added complexity, which for my case is completely unnecessary - I just wanted to be able to push text to a file on a server via ssh and have it visible as a post. I’ve looked at various other means of retaining text-based information over the years and everything that required an additional service in front of it, e.g. anything that has to render html like self-hosted wikis, would become a hassle to maintain and a chore to furnish.

On the other hand, the jumbled collection of text files sitting on my NAS haven’t been any further away than an SSH session and have seen far more use than the neatly formatted documents I’ve produced, in my personal experience.

ls, grep, cat depending on what I’m looking for, or to what extent I have any idea what I’m looking for - e.g. does the trailing slash go after the target or the source when running rsync on a directory…?

Workflow

General workflow I’ve adopted for this is sync the Hugo directory to a private git repo and call a simple script on the server that I host the site on via SSH.

Editor of choice, micro; preview in terminal via glow.

hugo new posts/file.md
micro ~/hugo/posts/file.md

My terminal emulator of choice is Tilix - I still prefer traditional window managers scattering stacks of oddly sized windows across my screen and moving them around with a mouse so I’ll generally open one terminal window and resize depending on the task at hand, using tabs and splitting windows. Less efficient? Yes. Can I unlearn decades of habits? No - and I don’t need to improve productivity any more than I already have, so that energy is better spent working on projects rather than forcing myself to adapt to the “proper” way to use certain tools. I still use X11, still use stable Debian builds everywhere, etc. - it works, and I have no reason to change that yet.

Splitting the terminal, I can have the top window as a clean preview of sorts - really only necessary if I’ve got a table or something actually needs to be “rendered” to visually parse if you’re lazy with the formatting. Markdown really should easy to read even as plain text, and the colors provided by micro or any other modern text editor that is aware of the syntax is generally more than enough to get the gist of it.

Calling glowloop <filename> where glowloop is a simple script to run glow in a while loop in screen:

1	#!/bin/bash
2	
3	function repeat () {
4		while true; do glow "$0"; sleep 1; done
5	}
6	
7	export -f repeat
8	
9	screen -mS glow bash -c repeat "$1"

More elegant solutions likely exist, but given how rare a preview is actually needed, I haven’t sought them out.

Using git for source control, push the post to the remote repo (in this case, a private Github repo) and call the build script on the remote host.

git add <filename>
git commit -m "changes made"
git push
ssh rwz@server bash /home/rwz/hugo/build.sh

Above commands aliased into a one-liner, so I just call hugobuild when I’m ready to submit the post; build script on the remote host runs git pull and hugo - the resulting public directory built by the hugo command is just symlinked and served by nginx.

With a remote repo, I can pick up writing from any device with a functional terminal (assuming I remembered to “save” by pushing my changes to a branch for that post). In 5 years when I’ve completely forgotten about this blog, the contents are still readily accessible in a plaintext format. When development on Hugo dies down and stops being updated or becomes some commercial product, I’ve still got a copy of the repo; even then, there aren’t any bugs with how I use it currently and a copy of the binary is really all that’s needed to generate the site. As long as there’s some means of serving static files, this system isn’t reliant on anything except my own backups (and Github, at the time of writing). A self-hosted git repo isn’t really difficult to spin up though - it’s just additional bandwidth and maintenance for me; the files being pushed to the repo aren’t sensitive in any way, especially since they’re almost all designed to be explicitly served on a public-facing website, and the use of git is really just a stand-in for basic file synchronization anyways - I could always just build with Hugo locally and scp the results to any host running the web server.