ubuntuusers.de

So, ich denke das Problem wird nun klarer.

Danke für die klärende Befehlszeile von trollsportverein.

Sobald man bei "wine" den Befehl "start" verwendet, erhält man das Problem. Da ich keine Applikation mit "start" laufen lasse, tritt das Problem bei mir nicht auf. Beispiel:

$ WINEPREFIX=$HOME/.PlayOnLinux/wineprefix/mp3DirectCut
$ wine $WINEPREFIX/"drive_c/Program Files/mp3DirectCut/mp3DirectCut.exe"
$ echo "Dieser Text erscheint nachdem mp3DirectCut beendet ist."
$ #----------------------------------------------------------------------
$ wine $WINEPREFIX/"drive_c/Program Files/mp3DirectCut/mp3DirectCut.exe" &
[1] 94429
$ PID=$!
$ ps -p $PID
    PID TTY          TIME CMD
  94429 pts/0    00:00:00 mp3DirectCut.ex
$ echo "Dieser Text erscheint, während mp3DirectCut läuft."
$ wait -f $PID
$ echo "Dieser Text erscheint nachdem mp3DirectCut beendet ist."
$ #----------------------------------------------------------------------
$ wine start /unix $WINEPREFIX/"drive_c/Program Files/mp3DirectCut/mp3DirectCut.exe"
$ PID=$!
$ ps -p $PID
    PID TTY          TIME CMD
$ # Das Programm "wine" ist bereits beendet, mp3DirectCut läuft.
$ PID2=$(pgrep mp3DirectCut)
$ ps -p $PID2
    PID TTY          TIME CMD
  94596 ?        00:00:00 mp3DirectCut.ex
$ wait -f $PID2
bash: wait: Prozess 94596 wurde nicht von dieser Shell gestartet.
$ # wine start erzeugt einen eigenen Prozess, der vom Startprozess abgekoppelt ist
$ # da wait dann nicht funktioniert, hilft nur waitpid
$ waitpid $PID2
$ echo "Dieser Text erscheint nachdem mp3DirectCut beendet ist."
$ #----------------------------------------------------------------------

Ergebnis: Beim Starten mit "wine" funktioniert der "wait" Befehl wie erwartet. Startet man allerdings mit "wine start", wird ein Prozess erzeugt, der vom Startprozess abgekoppelt ist und somit mittels "wait" nicht referenziert werden kann.

Mit "waitpid" wird allerdings ein "Dienstprogramm zum Warten auf beliebige Prozesse" verwendet, weshalb diese Vorgehensweise funktioniert. Einen kleinen Haken hat "waitpid" allerdings. Es ist in der 22.04LTS Distribution noch nicht enthalten sondern erst ab 23.10 verfügbar. Wer das Utility unter 22.04 nutzen will, muss halt den Backport selbst schreiben oder uuf den "start" Befehl verzichten.

Empfehlung: Wenn möglich auf das "wine" Konstrukt "start" verzichten (ja ist nicht immer sinnvoll).

Offb. läuft auch

/usr/lib/wine/wineserver64

und nicht wie ich angenommen hatte

/usr/lib/wine/wine64

Das Folgende sollte reichen vor xrandr.

sleep 4 && while ps aux | grep [w]ineserver64; do sleep 2; done > /dev/null

Das wäre ne Alternative zu wait. Der Nachteil ist natürlich so ist nur 1 Instanz von wine möglich.

So, und nun schaue ich mir doch mal später "wine" an, bisher keinen Grund gehabt. Klingt seltsam hier im Faden dennoch mitgeschrieben zu haben, ich weiss. 😬

Wer das Utility unter 22.04 nutzen will, muss halt den Backport selbst schreiben ...

Sorry, da war ich wohl zu schnell. Es muss nicht immer ein Backport sein. Ich habe unter 22.04 mir die neueren Quelltexte von GIT geholt und mal schnell nach kompiliert. Ich musste nicht mal am Quellentext schrauben!!! Aus diesem Grund hier die erforderlichen Schritte, wer das "waitpid" Utility auch gern haben will:

$ # lade SourceCode
$ wget -O util-linux-stable-v2.39.zip https://github.com/util-linux/util-linux/archive/refs/heads/stable/v2.39.zip
$ mkdir x; cd x
$ unzip ../util-linux-stable-v2.39.zip
$ ./autogen.sh 
$ ./configure
$ make waitpid
$ ./waitpid --help
$ cp -p waitpid ~/bin/

Es kann sein, dass derjenige, der sonst keine Programme schreibt, noch ein paar "Hilfsmittel" installieren muss (z.B. bison usw), aber das ist ja keine Herausforderung. Selbstverständlich ist die Ausgabe der obigen Skripte auf "Merkwürdigkeiten" zu analysieren, bevor man den nächsten Schritt startet.

Es sollte aber jedem klar sein, der an der Paketverwaltung vorbei arbeitet für sich derartige Aktionen zu dokumentieren! Spätere "Merkwürdigkeiten" am System bekommt man sonst schwieriger analysiert.

Ich glaube das gewünschte Verhalten funktioniert mit

wine start /wait ..

Damit wäre waitpid hinfällig.

wine start /wait ..

Gratulation. Den Qualifier kannte ich noch gar nicht. Aber "waitpid" brauche ich dennoch in einem anderen Zusammenhang. Somit mein build nicht hinfällig.

@shiro

Gratulation.

Oh, das gebührt Allen!

Hat sich entwickelt, war gut.

Danke an alle, die zum Thema beigetragen haben!

Anschließend noch ein paar Anmerkungen von mir:

Meine Version von Wine (Version 9) stammt direkt von winehq.org, weil die in der Distri verfügbare Version erst bei Version 6 steht. Darum ist der Befehl "wine" bei mir auch kein Shell-Skript:

file /usr/bin/wine
/usr/bin/wine: symbolic link to /opt/wine-stable/bin/wine

file /opt/wine-stable/bin/wine
/opt/wine-stable/bin/wine: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=e47871428b57e3cc1bf1ec023fbe66bdbbe0d787, for GNU/Linux 3.2.0, stripped

Das gleiche gilt für "wine64".

Weiterhin macht es tatsächlich einen Unterschied, ob ich wie in meiner Antwort weiter oben beschrieben eine Anwendung oder ein Spiel starte, indem ich die Windows-Verknüpfung aus dem Startmenü (die "lnk") oder das Windows Programm/Spiel (die "exe") direkt mit Wine starte. Mit folgendem Skript funktioniert auch der "wait" Befehl:

#!/bin/bash

export WINEPREFIX="/home/wolfgang/programme/black mirror/"
BM="$HOME/programme/black mirror/drive_c/GOG Games/Black Mirror 3/BlackMirrorIII.exe"
# funktioniert leider alles nicht:
# wine $BM
# wine ${BM}
# wine "$BM"
# wine "${BM}"

cd "$HOME/programme/black mirror/drive_c/GOG Games/Black Mirror 3"
wine ./BlackMirrorIII.exe
pid=$!
wait -f $pid
echo 'Wine hat fertig!'
/usr/bin/xrandr --output DisplayPort-0 --off --output DisplayPort-1 --primary --mode 3840x2160 --pos 0x0 --rotate normal

Allerdings funktioniert das nur, wenn ich in dem Skript expliziert in das Verzeichnis wechsle. Mehrere Versuche, Wine die Anwendung samt komplettem Pfad schmackhaft zu machen, haben nicht funktioniert, egal ob einfache oder doppelte Anführungszeichen, ob Leerzeichen mit "\ " maskiert, oder auch Übergabe des Pfades als Inhalt einer Variablen haben nicht funktioniert. Vielleicht gibt es noch eine Möglichkeit, die ich übersehen habe, aber wenn es über den Umweg mit dem Wechsel in das Verzeichnis funktioniert, macht mir das auch nichts aus.

Darum ist der Befehl "wine" bei mir auch kein Shell-Skript:

Sicher? Hier wird wine als..

Letztendlich landet das hier bei

file /usr/bin/wine-stable
/usr/bin/wine-stable: POSIX shell script, ASCII text executable

Also nur hier so.

–-

funktioniert leider alles nicht:

Absoluten Pfad probiert?, (also anstelle $HOME), Dann müsste doch gehen:

wine "$BM"

–

Mich würde mal interessieren, was bei Dir dann beim Lauf eigentlich aktiv ist.

wine
wine64
wineserver64

? Nur so.

Hier scheint Folgendes abzulaufen(wine-6.0.3):

wine(sym.L. ... → wine-stable(Script)) → wine64 → wineserver64

Marantkurz schrieb:

Hier scheint Folgendes abzulaufen(wine-6.0.3):

wine(sym.L. ... → wine-stable(Script)) → wine64 → wineserver64

Du hast bestimmt das Paket Wine aus der Ubuntu-Distri installiert. Ich dagegen habe die Pakete direkt von WineHQ installiert.

Schon klar.

shiro schrieb:

Es sollte aber jedem klar sein, der an der Paketverwaltung vorbei arbeitet für sich derartige Aktionen zu dokumentieren! Spätere "Merkwürdigkeiten" am System bekommt man sonst schwieriger analysiert.

Was dabei gemacht oder versucht wurde, kann man unter dem Label install aus der Datei Makefile ablesen. Und wenn man Glück hat, gibt es dort auch ein Label: uninstall.

Bei Programmen von Profi Programmierern sollte man das erwarten können.

Moin. *Kaffeetassegreif*

Aaaaalso, am einfachsten ist es doch, das mit "waitpid" zu machen. Hat man "waitpid" noch nicht, etwa wegen Jammy Jellyfish, dann kann man sich das doch auf Linux leicht selbst machen, ganz einfach rücksichtslos mit dem gleichen $PREFIX dahin ballern, wo es auch später nach Release Upgrades sein würde, unter "/usr/bin/waitpid".

Jetzt gehts los, von den kernel.org Servern holen, im Terminal:

https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.40/util-linux-2.40.tar.gz

Auspacken, konfigurieren und "waitpid" installieren:

tar -xvzf util-linux-2.40.1.tar.gz && \
cd util-linux-2.40.1 && \
./configure --prefix=/usr --disable-all-programs --enable-waitpid && \
time make -j $(nproc --all) && \
sudo make install-strip && \
/usr/bin/waitpid -V

Der letzte Befehl soll die Versionsnummer von "waitpid" ausgeben, es ist das zur Zeit neuste, neuer noch, als das default "waitpid" von Noble Numbat.

Die für Wolfgang.Klein und das "BlackMirrorIII.exe" in der Glaskugel voraus projizierte BlackMirrorIII.desktop Starterdatei. Das Icon muss aber noch ausgewählt und eingefügt werden.

[Desktop Entry]
Comment=
Exec=wine start /unix $HOME'/programme/black mirror/drive_c/GOG Games/Black Mirror 3/BlackMirrorIII.exe'; waitpid $(pgrep BlackMirrorIII.exe) && /usr/bin/xrandr --output DisplayPort-0 --off --output DisplayPort-1 --primary --mode 3840x2160 --pos 0x0 --rotate normal
GenericName=BlackMirrorIII Windows Spiel
Icon=<PFAD/ZUM/GEWÜNSCHTEN/ICON.ico>
Name=BlackMirrorIII
NoDisplay=false
Path=
StartupNotify=false
Terminal=false
TerminalOptions=
Type=Application
X-KDE-SubstituteUID=false
X-KDE-Username=

Gehört nach $HOME/.local/share/applications/BlackMirrorIII.desktop

Irgendwelche extra Bashscripte sollte™ es nicht brauchen, ist alles im Starter, "waitpid" macht es möglich. 😎 Sollte es nicht gleich im Menü sich zeigen, dann hilft ein Neustart, oder man versucht es erstmal mit einem:

kbuildsycoca5 --noincremental

... im Terminal.

Was den $PREFIX angeht und das überschreiben, dann, wenn es das "waitpid" aus DEB-Paketen gibt, dann wird es halt überschrieben. ¯\_(ツ)_/¯ Na und?

Dakuan schrieb:

Was dabei gemacht oder versucht wurde, kann man unter dem Label install aus der Datei Makefile ablesen.

Diese Aussage ist zwar korrekt, ich bezog mich bei der Bemerkung bezüglich "an der Paketverwaltung vorbei ... derartige Aktionen zu dokumentieren" aber darauf, dass es mehrere Paketverwaltungen (deb, snap, flatpak, pip, npm, lua, AppImage usw) gibt und es sich lohnt Aktionen bei diesen und den eigenen Programmen (bei mir sind es z.Zt. 197) ordentlich zu dokumentieren. Bei den Git-üblichen Aktionen (setup/configure/make) würde sonst ein Dokumentations-Teil fehlen. Bei Detailanalysen sind natürlich die Logs der jeweiligen Paketverwaltung bzw der "make"-Logs heran zu ziehen.