New CLI front-end for Syncthing's REST API.

I found need earlier today for an easy way to quickly trigger a rescan from the command-line, and found that there really isn’t one, so I’ve written a tool to do so, and it kind of evolved a bit from there with the intent of eventually being able to not need the web GUI at all.

Source code can be found here;

Currently, it’s pretty rudimentary (it only supports rescanning folders and overriding remote changes to send-only folders, and doesn’t have great error handling), but it works well enough that I felt comfortable putting it on Github so that other people can make use of it if they want.

Initial setup is dead simple, just run: setup /path/to/your/syncthing/config.xml and it will pull out the info it needs into it’s own config file in ~/.stcli.json.

I’m planning on adding a majority of the other currently used REST API calls as time permits (there are a handful that I plan on not adding for various reasons, see the README file in the repository for info).

1 Like

Nice! My syncthingmanager utility may have a few things implemented such as connection state that might be useful to your project, though I’m insane enough to make it mostly about the config endpoint :stuck_out_tongue_winking_eye:

1 Like

I’m actually surprised it didn’t come up when I was searching for something like this.

The funny thing is mine’s gone significantly beyond my original use case (poking Syncthing to rescan a folder after I update stuff so that the changes get pushed without having to run syncthing-inotify (It’s not packaged on Gentoo, and I’ve been unable to figure out why it only builds correctly sometimes)), but I’m still trying to stick to (mostly) simpler things that you can’t do with just a text editor and regular service management tools (so in my case, I’m making a point to not even touch the config endpoint, since I’m crazy enough to just edit the config by hand if I can’t get the UI safely proxied out over HTTPS)). I’m also being kind of picky about minimal dependencies (as it stands now, you can literally just copy to a system which has a new enough version of Python, and it should work without needing any further setup), which admittedly limits what I can do.

Yeah, my use case is more about not wanting to rely on GUIs when possible, and finding config.xml a bit too heavy for routine editing. I don’t think avoiding dependencies is all that limiting. Requests and python-syncthing mostly just save a bit of time and make error handling easier, which isn’t a big deal if you’re careful.

If you want to sapare end user problems with dependencies then you can always try to package your Python tool in pex file –