ローカルマシン上で gui を表示できるようにするために、シェル( bash )変数でDISPLAY
を検出する必要があるプロジェクトがあります。
または、DISPLAY
とXAUTHORITY
を理解せずに非対話型シェルで gui を開くためのより良い解決策( dbus ?)。
DISPLAY=:0
しかし、ユーザーが別のセッションを使用すると失敗します。
私がインタラクティブモードでない限り、私が試した(うまく機能しますが、ルートとしてのみ):
strings /proc/$(pidof Xorg)/environ | grep -Eo 'DISPLAY=:[0-9]+(:[0-9])*'
またはユーザーとして:
ps uww $(pidof Xorg) | grep -oE '[[:blank:]]:[0-9]+(:[0-9])*\b'
しかし、それがどのLinux(UNIX?)でも信頼できるかどうかはわかりません。
より信頼できる/ポータブルな方法はありますか?
rootである必要のない最終的なソリューションであり、自動化された方法で非インタラクティブシェルからアクセス可能であり、以前に提供された可能な複製リンクよりも高度で使用可能です:
-XAUTHORITY
:
ps -u $(id -u) -o pid= |
xargs -I{} cat /proc/{}/environ 2>/dev/null |
tr '\0' '\n' |
grep -m1 '^XAUTHORITY='
-DISPLAY
:
ps -u $(id -u) -o pid= |
xargs -I{} cat /proc/{}/environ 2>/dev/null |
tr '\0' '\n' |
grep -m1 '^DISPLAY='
スニペットは、すべてのユーザーのpids
をリストし、それらを反復して、最初の一致でブレークします
this に基づく
Init system systemd
のあるディストリビューションでは、
_systemctl --user show-environment
_
は、DISPLAY
およびXAUTHORITY
を示しています。これは、systemdおよび_gdm3
_をディスプレイマネージャーとして使用している私のdebian 9システムには少なくとも当てはまります。
落とし穴:tty2で_startx xterm -- :2 vt2
_を実行した後、systemctlは新しいディスプレイからDISPLAY
とXAUTHORITY
をくれました。私のメインディスプレイ_:0
_は、このように観察できなくなりました。
その他のアプローチ:
少なくともXAUTHORITY
の場合、_ps aux | grep Xorg
_の出力を解析してオプション_-auth
_を探す方が信頼性が高くなります。私の場合、それは_/run/user/1000/gdm/Xauthority
_ではなく_~/.Xauthority
_にあります。
落とし穴:
Xwayland
があります。Xvfb
または何か他のものがあります。通常、Xorg
コマンドにはディスプレイ番号も含まれます。残念ながら、私はしません:
_/usr/lib/xorg/Xorg vt1 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -background none -noreset -keeptty -verbose 3
_
_-displayfd 3
_はどういうわけかDISPLAY
を指します。 rootで/proc/$(pidof Xorg)/fd/3
を見ると
_ lrwx------ 1 root root 64 Mär 8 22:45 3 -> socket:[21437]
_
しかし、ソケット_21437
_を探す方法がわかりません。 _/tmp/.X11-unix/X0
_を指していると確信しています。 1つのアプローチは、興味深い出力を示す_lsof +E -aUc Xorg
_です。つまり、多くの接続が_@/tmp/.X11-unix/X0
_と1つのdbus
接続を含みます。
少し汚い:fd
フォルダーにも表示されます
_l-wx------ 1 root root 64 Mär 8 22:45 5 -> /var/log/Xorg.0.log
_
_Xorg.0.log
_は、表示_:0
_を明確に示します。
別のアプローチ:_notify-send
_はDISPLAY
とXAUTHORITY
をいくつかのdbus
マジックで集めているようです。しかし、私にはその手がかりがありません。少なくともdbusデーモンが実行されている場合は、これが最もクリーンで移植性の高い方法です。