[PATCH] Update xflock4 (Bug 10217) again

[Robby Workman]

On Thu, 19 Mar 2015 02:21:25 +0600
Alexander Mezin <mezin.alexander at gmail.com> wrote:

> Based on patch by Jarno Suni.
> 
> - Use pgrep instead of pidof, which is, hopefully, available
> everywhere.
> - Check screensavers running under current uid only.
> - Do not redirect output of lock commands to /dev/null. It could
> be useful for diagnostics.
> ---
>  scripts/xflock4 | 70
> ++++++++++++++++++++++++++++++++++++--------------------- 1 file
> changed, 44 insertions(+), 26 deletions(-)
> 
> diff --git a/scripts/xflock4 b/scripts/xflock4
> index ec4d05d..9580683 100644
> --- a/scripts/xflock4
> +++ b/scripts/xflock4
> @@ -4,7 +4,7 @@
>  #
>  #  Copyright (C) 1999, 2003 Olivier Fourdan (fourdan at xfce.org)
>  #  Copyright (C) 2011       Guido Berhoerster
> (guido+xfce.org at berhoerster.name) -#  Copyright (C) 2011       Jarno
> Suni (8 at iki.fi) +#  Copyright (C) 2014       Jarno Suni (8 at iki.fi)
>  #
>  #  This program is free software; you can redistribute it and/or
> modify #  it under the terms of the GNU General Public License as
> published by @@ -20,31 +20,49 @@
>  #  along with this program; if not, write to the Free Software
>  #  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
> 02111-1307, USA. #
> -
> -PATH=/bin:/usr/bin
> +set -o nounset
> +set -o errexit
> +# OpenBSD and possibly some other OSs require
> +# /usr/local/bin:/usr/X11R6/bin in PATH
> +PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
>  export PATH
>  
> -# Lock by xscreensaver or gnome-screensaver, if a respective daemon
> is running -for lock_cmd in \
> -    "xscreensaver-command -lock" \
> -    "gnome-screensaver-command --lock"
> -do
> -    $lock_cmd >/dev/null 2>&1 && exit
> -done
> -
> -# else run another access locking utility, if installed
> -for lock_cmd in \
> -  "xlock -mode blank" \
> -  "slock"
> -  do
> -    set -- $lock_cmd
> -    if command -v -- $1 >/dev/null 2>&1; then
> -        $lock_cmd >/dev/null 2>&1 &
> -	# turn off display backlight:
> -	xset dpms force off
> -        exit
> -    fi
> -done
> +check_running() {
> +    pgrep -U `id -u` -x $1 >/dev/null 2>&1
> +}
>  
> -# else access locking failed
> -exit 1
> +# Lock by a screensaver, if its daemon is running.
> +if check_running xscreensaver; then
> +    xscreensaver-command -lock
> +elif check_running gnome-screensaver; then
> +    gnome-screensaver-command --lock
> +elif check_running light-locker; then
> +    light-locker-command --lock
> +elif check_running mate-screensaver; then
> +    mate-screensaver-command --lock
> +elif check_running cinnamon-screensaver; then
> +    cinnamon-screensaver-command --lock
> +elif check_running xautolock; then
> +# Note: xautolock does not tell, if it succeeds in locking,
> +# so be sure to start the daemon properly.
> +    xautolock -locknow
> +# No daemon was found; use some available utility to lock:
> +elif command -v i3lock >/dev/null 2>&1; then
> +    i3lock --dpms --color=000000
> +else
> + for lock_cmd in \
> +    "xlock -mode blank" \
> +    "slock" \
> +    "slimlock"
> + do
> +  if command -v -- $lock_cmd >/dev/null 2>&1; then
> +     # Run the command in background
> +     $lock_cmd &
> +     # Turn off display backlight
> +     xset dpms force off
> +     exit
> +  fi
> + done
> + # None of the above worked. Access locking failed.
> + exit 1
> +fi

I've not yet tested this, but I like the idea, as it ideally will 
fix a bug I'm seeing here. The current xflock4 script seems to run
everything it finds, and the result is multiple unlocking required
after a sleep/wake cycle. A bit of debug logging in current xflock4
reveals this:

Ran xscreensaver-command -lock at Wed Mar 18 19:28:08 UTC 2015
Ran xscreensaver-command -lock at Wed Mar 18 19:28:09 UTC 2015
Ran gnome-screensaver-command --lock at Wed Mar 18 21:24:41 UTC 2015
Ran xlock -mode blank at Wed Mar 18 21:24:41 UTC 2015

The first two lines are at sleep time (no idea why the xscreensaver
part is getting exec'd twice, and the second two lines are at wakeup
time. Ignoring the two invocations of xscreensaver-command, it appears
that the exit code from that is not 0 and thus the gnome-screensaver
line runs, which definitely returns 1, so the latter two lines are 
then run after resume. I've added some additional debugging to this
for the next cycle, but that will have to wait a bit. Once I have that,
I'll test out your patch and see how that goes.

-RW