OnSongChange / OnStop only work in foreground

Submitted by slackhead on Mon, 2020-01-27 01:13

Forums:

MOC version: 
svn 2020-01-26

Hi,

Version: mocp svn pull earlier today.
zsh 5.6.2
Slackware 14.2 64bit.
screen 4.6.2
TERM=screen.linux (ssh'ing to server from plain tty/framebuffer)

I added some commands for OnSongChange and OnStop:

OnSongChange = "/home/david/scripts/moctitle %a %r %t"
RepeatSongChange = yes
OnStop = '/home/david/scripts/moctitle'

The moctitle script is just a short shell script to print song details to a
file in /tmp for reading by another application.

When it seemed not to be working I tried running mocp -F -D, and discovered it
works perfectly when running in the foreground.

I also ran it with only -D, and searched for OnSongChange in the scrollback,
but there was nothing.

Any ideas, or can I provide more info

jcf

Mon, 2020-01-27 06:13

It's not immediately obvious (in the brief time I've had today to look at it) that foreground or background would make any difference... provided your client (if that's how you are controlling the server) is connecting to the server instance you think it is.

The line in the mocp_server_log you should be looking for contains "Running command:", but you'll only get this if your MOC was configured with --enable-debug at build time.

jcf

Wed, 2020-01-29 21:05

I've tried running MOC in all the modes you suggest as well as several others and I cannot reproduce your problem. As well as that, running such "tattle-tale" scripts is something I do regularly in testing and I've not had any problem.

Please e-mail your moctitle script to mocmaint for further analysis.

slackhead

Tue, 2020-03-31 15:10

I'd forgotten about this thread. It's a very small script so I'll print it here. There are 2 actually:

[ -n "$1" ] && printf %s "$1" > /tmp/mocplaying
[ -n "$2" ] && printf %s "|$2" >> /tmp/mocplaying
[ -n "$3" ] && printf %s "|$3" >> /tmp/mocplaying
[ -n "$3" ] && /home/david/scripts/title "$3"
[ -z "$1" ] && printf "" > /tmp/mocplaying

And the `title' script only uses printf to set the screen window title to whatever is pass to it, but I could do it all from the first script really:

printf %b "\ek$@\e\\"

I'll have another look at it to see if anything else might be affecting it.

slackhead

Tue, 2020-03-31 16:07

I replaced the forth line:

[ -n "$3" ] && printf %b "\ek$3\e\\"

Everything works except that line. If I just run the script with dummy arguments it's fine:

moctitle test1 test2 test3

and the screen window is set to test3. But it doesn't set it when running it inside moc.

Dunno. Might be something to do with my shell or screen's dynamic titles. The other parts of the script are more important to me anyway.

jcf

Tue, 2020-03-31 20:20

My guess would be that it has to do with the only noticable difference - the escape sequences. From that, my second guess is that your are running your script in the shell under a different $TERM setting from that used when invoked by MOC.

Try adding this to the start of your fourth line: TERM=xyz (where xyz is the value of the TERM environment variable used by your shell).

slackhead

Wed, 2020-04-01 17:06

TERM is set to screen.linux in both. I'm in the same screen session. I wonder if it's a problem with $TTY not being set when run via moc. I get that sometimes with sometimes.

Well I just had it print $TTY and `tty` and it's `not a tty' so I think I'll need to redirect any echo or printf to the proper tty.

jcf

Wed, 2020-04-01 21:47

I have to come to the conclusion that the most likely cause is in the space between your script and what appears on the screen, and not within MOC itself. May I suggest that you do a search for something like "using escapes from scripts when using screen"?

But, maybe just double-backslashing the escapes will solve it.

slackhead

Thu, 2020-04-02 12:39

The usual way to escape commands in screen is to encpsulate them between \eP and \e\\ but it doesn't apply to screen commands themselves, because you don't want those to pass through to terminal underneath screen. The problem with tty showing `not a tty' means that the code doesn't go anywhere.

I tested redirecting the printf to /dev/pts/8 and it works like that, so the solution is to find the tty that moc is running on:

moctty=`ps o tty,comm | grep [m]ocp | awk '{print $1}'`
[ -n "$3" ] && printf %b "\ek$3\e\\" >> /dev/$moctty

jcf

Thu, 2020-04-02 20:03

That's a little unclear, but, based on it, would "\eP\ek$3\e\\" not work? (It's not clear to me whether the \k is an escape sequence
intended for GNU screen or for the terminal itself.)

But thanks for the solution.

slackhead

Fri, 2020-04-17 02:21

It's intended for screen itself, so an OSC code that makes screen send the code through to the terminal would have no effect.

I think the problem is that since `tty` is showing 'not a tty' then the printf will fail anyway, unless it's redirected to an actual tty as I did above. I've come across this problem in the past, when starting scripts from within other applications, or via cron/at etc. and I think it's a common one.