[Solved] how to find active X11 session's user and display?

[jazzbiker]

Hi, GNUser!

I think You don't need to concentrate on all this "nobody home" who's answer. These are busybox's jokes and they can not decline the fact, that if You start X server it has its own environment, which differs from the parent environment and DISPLAY is defined only in the child's environment but not in the parent's.

[GNUser]

Jokes continues. X started as tc, then in tty1 tc exited and logined as jb. Then in X opened new terminal:

Code: [Select]

tc@box:~$ su - jb -c 'echo $DISPLAY'
Password:

tc@box:~$ echo $DISPLAY
:0.0

in tty1

Code: [Select]

jb@box:~$ echo $DISPLAY

jb@box:~$ su - tc -c 'echo $DISPLAY'

jb@box:~$
tc can acces jb's environment, but jb can't access tc's.

jazzbiker, this is my interpretation of what's going on here:
- user "jb" does not have the DISPLAY variable defined in his environment. That's expected (jb is logged in to a console).
- user "tc" has the DISPLAY variable defined. That's expected.
- trying to show the value of tc's DISPLAY variable by switching to user tc using "su" doesn't work. That's unexpected.

[GNUser]

Assuming the most complicated situation (persistent /home for multiple users), I think I found a good-enough solution. Every user who starts an X session gets a  .Xauthority  file in their home directory. So a surrogate question might be: Who's the owner of the most recent .Xauthority file?

The  -t  flag to  ls  puts the most recent files on top, so something like this will give us the most recent  .Xauthority  file on the local machine. The -1 (that's the number one) is to ensure a single column so that "head" doesn't get confused:

Code: [Select]

$ ls -1t /home/*/.Xauthority | head -n 1
So I think this answers the first part of OP--how to find active X11 session's user?

Code: [Select]

$ ls -1t /home/*/.Xauthority | head -n 1 | cut -d/ -f3
Can you guys help me find the DISPLAY value (from outside X's environment) of that user's environment? It seems to be non-trivial (e.g., https://superuser.com/a/647484) and I don't want to assume that it is :0.0

P.S. I need the value of the user's DISPLAY so that a udev rule (which does not have the DISPLAY variable in its environment) can launch a GUI application.

[jazzbiker]

So someone will modify rule each time X starts? It may be some script, started immediately at X start.

[GNUser]

No, the udev rule is not meant to be changed. The udev rule is part of an extension that I want to share with others. Therefore, the udev rule cannot assume that everyone's DISPLAY is :0.0

I use Xorg-7.7 and not Xfbdev as you do. Just out of curiosity, does Xfbdev likewise create a  ~/.Xauthority  file?

[Rich]

Hi GNUser

... Can you guys help me find the DISPLAY value (from outside X's environment) of that user's environment? ...

If you can associate a PID with the user, then maybe this:

Code: [Select]

sudo grep "DISPLAY=" /proc/$PID/environ | cut -d '=' -f2

[curaga]

I think it's fine to assume :0, that will cover 99.9% of the users, and those who it doesn't cover can edit it.

It's rare to run multiple X servers at once, and the sub-screen number (.0) is only relevant in rare multi-monitor configs (separate screens, windows not draggable between them).

[jazzbiker]

Yes, Xfbdev uses Xauthority too.

[GNUser]

So one way to find X11 session's user and display is like this:

Code: [Select]

user=$(ls -1t /home/*/.Xauthority | head -n 1 | cut -d/ -f3)
display=$(for PID in $(ps | awk "\$2 == \"$user\" { print \$1 }"); do grep "DISPLAY=" /proc/$PID/environ 2>/dev/null; done | head -n 1 | cut -d= -f2)
Rich, that was an amazing tip. Wow. Thanks.
curaga, good to know that :0 is a reasonable assumption. I guess users who are savvy enough to setup multiple displays will know to edit it.
jazzbiker, thank you very much for helping me work through this.

You guys are the best!

Thread may be marked as "Solved".

[GNUser]

Thanks, jazzbiker. Good to know

[jazzbiker]

Thanks, if You will use this not for TC only I hope You will not forget to use ps with ax switches or even aux.
Your threads are great sources for me, thanks again.

[Rich]

Hi GNUser

...

Code: [Select]

user=$(ls -1t /home/*/.Xauthority | head -n 1 | cut -d/ -f3)
display=$(for PID in $(ps | awk "\$2 == \"$user\" { print \$1 }"); do grep "DISPLAY=" /proc/$PID/environ 2>/dev/null; done | head -n 1 | cut -d= -f2) ...

If you've ever looked through the scripts I've posted, you may notice I often use aliases back to the busybox versions.
This is to reduce the chance of breakage due to possible different behavior of the GNU version if it gets installed. The
ps  command is a prime example of such behavior. If procps.tcz gets installed, the ps command will return this:

Code: [Select]

tc@box:~$ ps
  PID TTY          TIME CMD
25558 pts/2    00:00:00 sh
25569 pts/2    00:00:00 ps
tc@box:~$instead of the long list the busybox version returns.

[GNUser]

TCL comes with an aliases file for this very purpose, so there's no need for us to rewrite our own aliases. If you want to specifically use the BusyBox version of the commands (as opposed to the GNU versions in coreutils.tcz, procps.tcz, sed.tcz, etc.), then put this near the top of your script:

Code: [Select]

. /etc/init.d/busybox-aliases

[Rich]

Hi GNUser

TCL comes with an aliases file for this very purpose, ...

Yes, yes it does.

... so there's no need for us to rewrite our own aliases. ...

Unless the command you want aliased to busybox is not in that file, like  ps  for instance.

[GNUser]

Unless the command you want aliased to busybox is not in that file, like  ps  for instance.

https://github.com/tinycorelinux/Core-scripts/pull/14
It is now

By the way, why aren't all the BusyBox commands that are compiled into TCL's BB binary included in /etc/init.d/busybox-aliases? Having to check whether a particular BB command is included in the aliases file seems like an unnecessary complication.

If calling the  useBusybox  function in  tc-functions  only works for some BB commands, the function seems unreliable.

Is having aliases for only a subset of BB applets intentional or a bug/oversight? If the later, I can submit another pull request with all the rest of the missing applets.