💾 Archived View for tilde.team › ~benk › 0f175442.gmi captured on 2021-12-03 at 14:04:38. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Scripting Tasks With Diohsc

Authors: Ben K. <benk@tilde.team>

Date: 2021-06-02

Some time ago I wrote a post about how one could extend Diohsc's behavior by allowing it to call scripts or other programs while passing simple data to them. In this post we are going to do the opposite and have a script invoke Diohsc in order to perform a task for it.

Because Diohsc allows you to invoke it from the command line with preset commands, it can run non-interactively and therefore be used to perform automated tasks. Diohsc's command system is powerful enough to allow you to do things like visit URI's, identify the client to the server, and send query data to the server.

In my first example, I added a line to my gemcast's script in order to post new gemcast episodes to Station, Gemini's social network. The easiest way to do this is to create a mark to the URI you are planning to invoke that includes your identity. So in ~/.diohsc/marks/nl (in Station a new post is referred to as "New Log") I have the following URI:

gemini://station.martinrue.com/benk/2fdf/post[benk]

"benk" is the name of the identity I plan to use, which has already been created during my normal use of Diohsc. This allows me to do something very simple in my script like:

diohsc -e "'nl query $post"

All this will do is query the link (identity included) and send the post. For each command we want Diohsc to execute, we must use the -e option, and in this case it's only one.

Much later, I found out that something can go wrong when running automated commands like this, which is that if server's cert doesn't check out for whatever reason, the request will fail because Diohsc is running non-interactively and can't ask you what to do. One way to get around this is to delete the site from ~/.diohsc/known_hosts/ so that Diohsc will automatically do TOFU (trust on first use), but deleting the site's cert every time is less than ideal.

Instead of deleting the cert, Martin suggested running Diohsc in "ghost" mode, which forbids it from writing to the disk. While doing this, you also specify a custom Diohsc directory that doesn't contain known_hosts. This is a good idea for scripting when you are comfortable with blindly accepting whatever cert the server throws your way. You probably won't always want to do this, but in my next example there shouldn't be a problem with it.

Therefore, to auto-accept certs, I create a directory ~/.diohsc-static (you can name it whatever you want), and let it contain just the identities and marks needed for doing my tasks. Then I can invoke Diohsc as so:

diohsc -g -d ~/.diohsc-static

The fact that no data gets written to the disk makes this solution nifty, particularly for cron jobs. In this example, I want to water my plant every day in Astrobotany:

In order to do this, I first created marks for all the URI's involved. As with the first example, this is probably not the only possible way to do this, but it appears to be the best. My marks are:

'plant           gemini://astrobotany.mozz.us/app/plant[benk]
'shake           gemini://astrobotany.mozz.us/app/plant/shake[benk]
'water           gemini://astrobotany.mozz.us/app/plant/water[benk]

Now we are finally ready to create our cron job:

0 0 * * * diohsc -g -d ~/.diohsc-static -e "'plant identify benk" -e \'water -e \'shake

If you happen to not be familiar with cron, the first part of the line tells the computer when to run job, with minutes first and hours second, so this would run every day at midnight. (On my system, the time and date part can be replaced by aliases like "@daily".)

What the above command does should be fairly obvious. The reason for using 'plant is that when you water and shake your plant, the server will redirect your client to /app/plant, and Diohsc needs to know which identity to use for this because it won't assume that the ID you used for a subdirectory can or should be used for a higher level directory.

In this example, what the "identify" command does for us is prepares Diohsc to use the identity "benk" for /app/plant (and sub-items) while saving Diohsc from actually having to request the URI. In other words, "identify" only preps the client for future requests and is not a request in itself. I could have simply requested 'plant since the mark itself contains the ID, but why do three requests when you do just two? :)

As a consequence of doing it this way, it happens to no longer be necessary for the marks to contain the ID, but having them there doesn't hurt anything. After all, I do use 'plant during my normal browsing sessions. I suppose if you had multiple accounts you might not want the marks to be set to a specific ID.

The actions being performed, "water" and "shake", are the ones I believe you'd ideally want to do every 24 hours. However, I'm not an expert in Astrobotany's game mechanics, so I do not know what the precise values are. For example, you might want to set up a separate cron job to fertilize your plant or perform other actions, but I noticed that fertilizer lasts for more than one day, and I don't actually know how long it lasts. (If you want to get super fancy, you might even be able to eventually create yet another a job that buys more fertilizer for you!)

And of course, the point of all this is not to have Astrobotany play itself, which wouldn't be so fun, but automating the daily tasks actually makes quite a bit of sense. You don't want your plant to die just because you forgot about it for a few days! Do bear in mind, however, that forgetting to water you plant is actually a part of the game, and so part of the fun is the social aspect and having your friends water your plant for you when you can't or don't do it, so do be sure that automation is really what you want as it can take something away from the game experience.