xtrlock works from menu but not from Key command. Why?

Configuration General Questions
1

I have the following menu:

DestroyMenu     RootMenu
AddToMenu       RootMenu
+ "Root Menu"         Title
+ "xterm"           Exec exec xterm 
+ "Applications"    PopUp Apps
+ "X functions"     PopUp XStuff
+ "All Programs"    PopUp "/Debian"
+ "Desktop"         PopUp Desk_Ops
+ "Lock"            Exec exec xtrlock

Mouse 3         r       n       Menu "RootMenu" Nop

and the “Lock” entry works as it should, causing the screen to lock. I wanted a keyboard command, so I tried this:

Key Scroll_Lock A N Exec exec xtrlock

but it doesn’t work. The Key command is working. If I substitute xterm for xtrlock it brings up xterms. So what is the difference between running a command from a key and running it from the menu that would explain why this works in one place and not the other?

2

What’s in ~/.xsession-errors, or wherever FVWM is logging to STDERR?

– Thomas Adam

3

I did not see any relevant messages in the error log. The error log is attached below in case you don’t trust my assessment of relevance. Note that I also tried replacing xtrlock with a script

#!/bin/sh

echo locking >> /tmp/lock.log
xtrlock >> /tmp/lock.log
echo done locking >> /tmp/lock.log

to make sure that it was actually running. I pressed Scroll Lock repeatedly. You can see that the script ran by inspecting /tmp/lock.log which has this in it:

locking
done locking
locking
done locking
locking
done locking
locking
done locking
locking
done locking
locking
done locking
locking
done locking
locking
done locking
locking
done locking
locking
done locking
locking
done locking
(additional lines deleted)

Things appear to be weird than I realized: In the process of running this test to produce a well documented error log for you I discovered that if I press Scroll Lock rapidly in succession the xtrlock program sometimes actually locks the screen. A quick test of a sequence of double pressing Scroll Lock I observed it to lock 5 times out of 20 sets of double presses. (By “double press” I mean press, release, press, release as quickly as possible.) A sequence of 40 single presses never caused it to lock. Triple pressing seems to reliably lock.

The .xsession-errors file starting from an FVWM restart:

(pavucontrol:29509): Gdk-WARNING **: The program 'pavucontrol' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
  (Details: serial 10163955 error_code 3 request_code 18 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

[fvwm][ReadDecorFace]: <<ERROR>> unknown button face flag 'HiddenHandles,' -- line: -- HiddenHandles, NoInset
[fvwm][FlocaleGetFontSet]: (-adobe-times-bold-r-normal--14-140-75-75-p-77-iso8859-1) Missing font charsets:
ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1
[FvwmIconMan][FlocaleGetFontSet]: (-adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1) Missing font charsets:
ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1
[buttonbar][FlocaleGetFontSet]: (fixed) Missing font charsets:
ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1
[termbutton][FlocaleGetFontSet]: (fixed) Missing font charsets:
ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1
[soundcontrol][FlocaleGetFontSet]: (fixed) Missing font charsets:
ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1
[units][FlocaleGetFontSet]: (fixed) Missing font charsets:
ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1
** (pavucontrol:32765): DEBUG: Ignoring sink-input due to it being designated as an event and thus handled by the Event widget
** (pavucontrol:32765): DEBUG: Failed to initialize device manager extension: No such extension
4

Then it has nothing to do with FVWM.

– Thomas Adam

5

Since the only way I have now to demonstrate the problem is with the “Key” command in FVWM do you have any suggestions as to how to disentangle the problem from FVWM to figure out what is going on? (This program is 100% reliable when run from the command line or when invoked from the menu.) Is there no difference at all detectable by a program invoked from a menu as opposed to invoked from the FVWM Key command?

Actually I found that the Mouse command also shows the problem:

Mouse 1         r       a       Exec exec xtrlock
6

[quote=“adrian”]
Since the only way I have now to demonstrate the problem is with the “Key” command in FVWM do you have any suggestions as to how to disentangle the problem from FVWM to figure out what is going on? (This program is 100% reliable when run from the command line or when invoked from the menu.) Is there no difference at all detectable by a program invoked from a menu as opposed to invoked from the FVWM Key command?

[quote=“adrian”]

It might need a controlling TTY.

– Thomas Adam

7

Would it have a controlling tty if it was run from the menu but not from Key or Mouse?

No. But there’s nothing special about running it from a menu or from key/mouse bindings.

– Thomas Adam