Sometimes I try things that sound good while they’re bouncing around in my brain, but after they’re done, I wonder why I bothered.
A long time ago, someone posted a method for trapping rtorrent in screen session and running it as a daemon. Attaching to the screen session gave normal users a way of controlling it.
Detaching from screen meant it continued to run in the background, so long as it wasn’t told outright to quit. And since it started as a system service, just turning on the machine put it into action.
The goal there was similar — to start up an application with the system, devote a single virtual console to it, and allow the user to bounce back and forth to that tty as a means of running it.
Last week during my forced hiatus, I tried a hybrid of those two, and more or less managed to run mc as a daemon, also within screen and with it triggered at bootup.
It wasn’t quite successful though (you probably guessed that, didn’t you?). In the time that has elapsed since the original post about rtorrent-plus-screen, things seem to have changed in the way those things work.
To summarize, I couldn’t get the ownership issues sorted out. The autostarting instance of screen was for some reason invisible to a normal user, which of course defeated the purpose.
Trying to shift the burden to tty1 only confused things. screen balked, and my configurations were somehow inaccessible.
Without a .screenrc that I could cue, tty1 opened up as a vanilla screen session, and then refused to budge beyond the welcome message.
Of course, after all was said and done, I began to wonder why I was bothering with the idea at all. Midnight Commander is a tiny little program that runs fine on every machine in the house.
And I couldn’t even use the excuse that it was somehow easier to invoke that way, since you can start mc with three keystrokes. 🙄
Short of assigning a custom keypress to the
mc command, it doesn’t get much simpler than
Still, science demanded an answer. Unfortunately, this time my answer was gibberish. 😐