I should have a separate category for CLI utilities of graphical programs. Inkscape would be on there. So would deluge, avidemux, handbrake and a bunch of other titles. You can add Transmission to the list now.
The CLI version appears in both Arch and Debian as “transmission-cli,” which I suppose is the obvious title for it, given how it appears on screen.
Use is fairly straightforward — trigger transmission-cli and follow it with a torrent name. Bandwidth settings and a few other points are controlled as flags. On-screen, you get a healthy log of the network and software transactions, as well as a progress indicator and speed meters.
The Arch package specifically installs with a daemon version and a few other related tools, including a torrent creator utility. That alone might be worth keeping track of.
I should mention as a side point that transmission-cli appears to be different from transmission-remote-cli, which should be a tool for accessing a machine that’s running Transmission, from a distance.
I’m not sure what the relationship is between the two; it’s a little confusing to me that the home page for Transmission links to transmission-remote-cli, but I don’t see a mention of just transmission-cli. I’m also not sure transmission-remote-cli can negotiate with transmission-cli. You’ll have to do the footwork there.
I should probably try out transmission-remote-cli though, because the screenshots on the git page look promising. I think the actual arrangement of the remote machine running Transmission might make it a challenge though. I’ll save that for another day.
In any case, if you prefer the Transmission way of doing things but can’t bear to live life without your blinking cursor, this might be one way to have it both ways. 😉
Inconsolation 
transmission-daemon and transmission-remote-cli can be on the same host. The latter provides a ncurses interface to the former that can be closed leaving transmission chugging away.
I think I understand. I took it to be that transmission-cli was the text-based interface to the regular Transmission tool. And that transmission-remote-cli was a way to access that tool on a machine running remotely. Does that mean transmission-remote-cli could access transmission-cli? Or could transmission-remote-cli be used as a way of controlling Transmission from the same machine, instead of transmission-cli?
My head is starting to hurt after that last one. … 😐
Sorry for being unclear.
The command ‘transmission-cli’ starts a stand-alone instance of transmission; however, transmission also sports a client-server model with four additional ways to interact with it so you can seperate the backend that handles the transfers from the front end that handles user interaction.
‘transmission-daemon’ starts the daemon and is included in Arch’s transmission-cli package. If you wanted it always on you could use any number of methods. Systemd would work well in your case.
The daemon has a built-in web server that you can use (enabled by default) to interface with the daemon using your browser of choice. This works locally or remotely.
Additionally there is a QT and a GTK GUI front end available. Currently the GTK front end only connects to locally running daemons while the QT one can connect to remotely running daemons.
transmission-remote-cli is yet another means to interface with a running transmission-daemon. It uses ncurses. Running it without any arguments will connect to a locally running transmission-daemon. You can also use it to connect to a remotely running daemon.
Which method you chose is probably driven by how much torrenting you do. For me, I run the daemon with a user systemd service file and have the web server disabled. I have it watch my downloads folder for .torrent files and I have a wrapper script for fandling magnet links. I like the ncurses interface as a balance of usability and lighness.
Did that clear it up?
Pingback: pirate-get: A tool is just a tool | Inconsolation