Programmausgabe lässt sich nicht umlenken

[Ulidor]

Aus einem Bash-Skript heraus, das von KDE-Autostart gestartet wird, möchte ich den Mediaplayer MPV mit dem Programm xdotool steuern.
Da gibt es z.B. diesen Aufruf, um mit der Taste p zwischen Wiedergabe und Pause hin und her zu schalten:

Code: Alles auswählen

xdotool key --window "$(xdotool search --class mpv)" p

Das klappt auch. Wenn aber der Befehl ausgeführt wird, wenn MPV nicht läuft, sieht die Ausgabe so aus (hier jetzt in der Konsole):

Code: Alles auswählen

rolf@ulidor:~ $ xdotool key --window "$(xdotool search --class mpv)" p
prolf@ulidor:~ $ p

Vor dem Prompt steht dann ein p und dahinter noch eins. Abgesehen davon, dass ich keine Ahnung habe, wo die beiden p herkommen, bekomme ich sie auch nicht durch Umleiten weg:

Code: Alles auswählen

rolf@ulidor:~ $ xdotool key --window "$(xdotool search --class mpv)" p &> /dev/null
prolf@ulidor:~ $ p

Code: Alles auswählen

rolf@ulidor:~ $ xdotool &> /dev/null key --window "$(xdotool search --class mpv)" p
prolf@ulidor:~ $ p

Code: Alles auswählen

rolf@ulidor:~ $ (xdotool key --window "$(xdotool search --class mpv)" p) &> /dev/null
prolf@ulidor:~ $ p

Auf der Kommandozeile ist das nicht weiter schlimm. Aber mein Skript dient dazu, MPV über die Fernbedienung meines Fernsehers steuerbar zu machen. Wenn ich da die Pausetaste drücke, wird der obige Befehl ausgelöst. Wenn MPV aber gar nicht läuft, öffnet sich am oberen Bildschirmrand die Befehlseingabezeile und es steht p darin.

Wie bekomme ich die Ausgabe der Kommandozeile weg?

[Meillo]

Vielleicht schreibt mpv nicht nach stdout oder stderr, sondern direkt nach /dev/tty. In dem Fall kannst du es nicht umleiten.

EDIT: Gemeint ist `xdotool', nicht `mpv'.

[JTH]

Wenn mpv nicht läuft, wird

Code: Alles auswählen

xdotool search --class mpv

nix ausgeben? Du übergibst xdotool per --window dann einen leeren String? Der Default scheint der manpage nach zu sein, die Tastatureingabe dann für das aktuelle Fenster zu simulieren. Wenn mpv nicht läuft, sendet

Code: Alles auswählen

xdotool key --window "" p

das p also an dein laufendes Terminalfenster.

Eine Outputredirection wird dir also vermutlich nicht helfen, das p kommt nicht über stdout oder stderr. Du musst eher ausschließen, dass xdotool key mit leerem Argument hinter --window aufgerufen wird.

Herleitung nur basierend auf der manpage, habe xdotool noch nie benutzt. Ohne Gewähr

[Ulidor]

Eine Outputredirection wird dir also vermutlich nicht helfen, das p kommt nicht über stdout oder stderr. Du musst eher ausschließen, dass xdotool key mit leerem Argument hinter --window aufgerufen wird.

Ah, okay. Und da xdotool ja den Tastendruck p simuliert, ist das quasi so, als würde ich selbst das p auf der Tastatur drücken, während das Terminalfenster aktiv ist. Ich habe jetzt mal bei aktivem Terminalfenster und nicht laufendem MPV die Pausetaste auf der Fernbedienung gedrückt. Da erscheint dann das p an der Curserposition.

@Meillo: Das bestätigt dann ja auch deine Vermutung, dass xdotools (das meintest du vermutlich) diese Ausgabe weder in stdout noch in stderr schreibt.

Okay, dann weiß ich Bescheid. Ich danke euch!

[Ulidor]

Ich habe das jetzt erst mal so gelöst:

Code: Alles auswählen

window=$(xdotool search --class mpv); [ "$window" != "" ] && xdotool key --window $window p

[Meillo]

Ich kenne mpv nicht, aber wenn das irgendwie mit dem mplayer verwandt ist, dann geht es vielleicht auch einfacher. Beim mplayer kann man naemlich eine FIFO anlegen, in die man dann Befehle reinschreibt. So brauchst du nicht mehr in ein Terminal schreiben. Vielleicht ist das ein hilfreicher Hinweis.

Code: Alles auswählen

mkfifo /tmp/mplayercontrol
mplayer -input file=/tmp/mplayercontrol ...

echo pause >/tmp/mplayercontrol

(Ich habe bei mir mit xbindkeys Befehle auf Sondertasten auf der Tastatur gemappt.)

[eggy]

manpage sagt

USING MPV FROM OTHER PROGRAMS OR SCRIPTS
There are three choices for using mpv from other programs or scripts:

1. Calling it as UNIX process. If you do this, do not parse terminal output. The terminal output is intended for humans, and may change any time. In addition, terminal behavior
itself may change any time. Compatibility cannot be guaranteed.

Your code should work even if you pass --no-terminal. Do not attempt to simulate user input by sending terminal control codes to mpv's stdin. If you need interactive con‐
trol, using --input-ipc-server is recommended. This gives you access to the JSON IPC over unix domain sockets (or named pipes on Windows).

Depending on what you do, passing --no-config or --config-dir may be a good idea to avoid conflicts with the normal mpv user configuration intended for CLI playback.

Using --input-ipc-server is also suitable for purposes like remote control (however, the IPC protocol itself is not "secure" and not intended to be so).

und

--input-ipc-server=<filename>
Enable the IPC support and create the listening socket at the given path.

On Linux and Unix, the given path is a regular filesystem path. On Windows, named pipes are used, so the path refers to the pipe namespace (\\.\pipe\<name>). If the
\\.\pipe\ prefix is missing, mpv will add it automatically before creating the pipe, so --input-ipc-server=/tmp/mpv-socket and --input-ipc-server=\\.\pipe\tmp\mpv-socket are
equivalent for IPC on Windows.

See JSON IPC for details.

und

JSON IPC
mpv can be controlled by external programs using the JSON-based IPC protocol. It can be enabled by specifying the path to a unix socket or a named pipe using the option --in‐
put-ipc-server. Clients can connect to this socket and send commands to the player or receive events from it.

WARNING:
This is not intended to be a secure network protocol. It is explicitly insecure: there is no authentication, no encryption, and the commands themselves are insecure too. For ex‐
ample, the run command is exposed, which can run arbitrary system commands. The use-case is controlling the player locally. This is not different from the MPlayer slave proto‐
col.

Socat example
You can use the socat tool to send commands (and receive replies) from the shell. Assuming mpv was started with:

mpv file.mkv --input-ipc-server=/tmp/mpvsocket

Then you can control it using socat:

> echo '{ "command": ["get_property", "playback-time"] }' | socat - /tmp/mpvsocket
{"data":190.482000,"error":"success"}

In this case, socat copies data between stdin/stdout and the mpv socket connection.

See the --idle option how to make mpv start without exiting immediately or playing a file.

It's also possible to send input.conf style text-only commands:

> echo 'show-text ${playback-time}' | socat - /tmp/mpvsocket

But you won't get a reply over the socket. (This particular command shows the playback time on the player's OSD.)

Command Prompt example
Unfortunately, it's not as easy to test the IPC protocol on Windows, since Windows ports of socat (in Cygwin and MSYS2) don't understand named pipes. In the absence of a simple
tool to send and receive from bidirectional pipes, the echo command can be used to send commands, but not receive replies from the command prompt.

Assuming mpv was started with:

mpv file.mkv --input-ipc-server=\\.\pipe\mpvsocket

You can send commands from a command prompt:

echo show-text ${playback-time} >\\.\pipe\mpvsocket

To be able to simultaneously read and write from the IPC pipe, like on Linux, it's necessary to write an external program that uses overlapped file I/O (or some wrapper like .NET's
NamedPipeClientStream.)

[Ulidor]

Okay, ich sehe schon, mit dem IPC-Server kann man ganz schön viel machen. In einem Beispiel kann man die Playback-Zeit im OSD anzeigen lassen. Sowas wäre auch nicht schlecht. Meillo, das scheint wirklich so ähnlich zu sein wie bei mplayer. Und ich habe im Skript sowieso schon eine FIFO, um die vom IR-Server geschickten Befehlswörter im Skript verwenden zu können, da kommt es auf eine zweite auch nicht an.

Ich werde mich damit befassen, sobald ich mehr Zeit dafür habe. Im Moment reicht mir die derzeitige Lösung.

Ich danke euch für die Hinweise!