Hi!
I'm not sure if I can help you to 100% solve your issue, but here what I can tell:
As I see, cmus is a TUI player, which means it's designed to be controlled from the terminal. One can think of it as being similar to GUI program, like VLC player, for example, which is usually opened once, in its own window and can not be actually 'put in the background' or 'suspended'. I mean, you can suspend it with
kill(1) for example, but it would not work as you would expect. Now, this is the point: such program is supposed to have its own window that will already be opened. In the analogy with GUI media player, we do not actually 'put the program in the background', we just minimize the window by means of window manager (but the window with process running in it is still there).
I was not familiar with
cmus(1), but I installed it and quickly read through its manpage and I didn't find any CLI switch that would potentially do the trick. But in fact, you already mentioned
tmux(1) as a solution and if you want to use exactly cmus and have the results you want, I believe that tmux would be the most sensible solution here: you see, tmux is a terminal multiplexer and session manager, it's sort of DE from the TUI world, so you can dedicate a separate session for cmus and then just detach from it (or just hide its window with your window manager).
But, I can share another example, with another player -
mpg123(1), you may find it interesting:
mpg123 is not a TUI player - rather, it's a CLI one let's say: it takes a list of files as input and produces output, which can be send to file (in basic usage, output goes into your sound card
/dev/dsp, which is also a file). It can be controlled from terminal as well, but it's not necessary. So, if you would try to launch it in mode, where you can control it from terminal, there would be no way to 'suspend' the job and expect it would continue to produce sound, because the program itself, once recognized that it would use a terminal controls, would not produce output when job is suspended, or put in the background, and this kind of sensible, because user can not control it then. But mpg123 provides a
--no-control option, which launches the player without ability to control the music playing. In this case, you now can put the job in the background:
mpg123 --no-control music.mp3 & and after that get your prompt back, but it doesn't have much sense - you can't control the track.
For this, there is a remote control. In this mode, the program will read control-commands from either stdin or a separate fifo file (see
mkfifo(2)). And we can use that to have both: 1) player job in the background and our prompt back, and 2) opportunity to control the music.
It would look like this:
Code:
$ mpg123 --fifo /tmp/mpg123 -R --no-control &
$ # our prompt is back!
And now, we can control it from whatever other place (from another terminal, or from the same we started player in):
Code:
$ echo LOAD music.mp3 >/tmp/mpg123
$ # music is playing now.
$ echo PAUSE >/tmp/mpg123
$ # music is stopped
and so on...
If desired, we can set up custom keybindings (e.g. with
xbindkeys(1)) for controlling the player (by means of writing to fifo as well).
If this is what you would like to do, you can do this with cmus as well - it also has a remote-control facility (see
cmus-remote(1)).
