On Tue, Aug 14, 2007 at 06:58:46PM +0100, seventh guardian wrote:
> On 8/14/07, Dominik Vogt <[EMAIL PROTECTED]> wrote:
> > On Tue, Aug 14, 2007 at 09:15:21AM -0400, Dan Espen wrote:
> > > "seventh guardian" <[EMAIL PROTECTED]> writes:
> > > > I must confess I'm not very fond of listen only modules. I believe it
> > > > is more of a hack than a long term solution to the "shell script
> > > > module" problem. And I would really like it removed, and for that the
> > > > sooner the better.
> > > >
> > > > So I was messing around to see if it was really needed, and it's not.
> > > > The pro
> > > > of:
> > > >
> > > > run "Module FvwmCommandS"
> > > >
> > > > create a simple bash script like this:
> > > >
> > > > #!/bin/bash
> > > > echo 'Module FvwmBanner' > /var/tmp/FvwmCommand-${HOSTNAME}${DISPLAY}C
> > > >
> > > > Now a nice FvwmBanner will appear. You can build complicated scripts
> > > > in any language that allows you to write to a file, zsh included, no
> > > > overhead whatsoever.
> > > >
> > > > And if you want to listen to fvwm it's a matter of listening to the
> > > > 'M' counterpart: /var/tmp/FvwmCommand-${HOSTNAME}${DISPLAY}M
> > > >
> > > > The only issue I can see here is the possible variation of the fifo
> > > > names, which is not that severe.
> > > >
> > > > Any reasons to keep the ListenOnly module mechanism?
> > >
> > > Compatibility?
> >
> > I just coded it a while ago for my own purposes, so that's no
> > problem.
> >
> > > Running FvwmCommandS is a security exposure.
> > > Some users might be reluctant to use it.
> >
> > I don't use FvwmCommand because it's too slow. I wanted a solution
> > for displaying a clock and the process using the most cpu with as
> > little overhead as possible. I do not want to start an executable
> > every n seconds because it has a negative influence on my system,
> > (namely the graphics performance of Kobo-Deluxe). I didn't do it
> > for the fun of it but to solve a real problem.
>
> You missed my point, I'm not using FvwmCommand, but only FvwmCommandS.
> FvwmCommandS creates two fifos that can be used to send and receive
> text to/from fvwm. So instead of calling FvwmCommand, you can directly
> write commands to the command fifo. So really NO overhead at all.(attached my fvwm_periodic script for reference) I see. But this has several important issues: * The "module" never notices that fvwm has gone away. Every time I restart I get another "module". At the moment it catches the PIPE signal and terminates, just like every other module. * It would have to guess the pipe's name. Note that I ofthen run multiple fvwms on separate displays, so it would not do to hard code /var/tmp/FvwmCommand-zitrone.obstwiese:0.0M (or 0.0C?). > As for the security issues, they can easily be circumvented by putting > the fifo in the user home dir. The -f option of FvwmCommandS currently does not allow to add the display name in the path, so it is difficult to have multiple "modules" on different displays at the same time. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de
#!/usr/bin/zsh
emulate zsh
setopt HUP
zmodload zsh/zselect
[EMAIL PROTECTED]
MODULE="FvwmButtons"
IDCLOCK=""
IDPROC=""
SECS="15"
ISECS="3"
usage () {
echo "usage: module-args $0 [-c id] [-t id] [-m module] [-u secs] [-d
delay]"
echo "Update certain button titles in FvwmButtons"
echo " module-args: filled out by fvwm when started as a module"
echo " -h: display this help message"
echo " -c buttonid: update clock at the given button id"
echo " -t buttonid: update topproc at the given button id"
echo " -m module: name of the module [$MODULE]"
echo " -u secs: update buttons every secs seconds [$SECS]"
echo " -d secs: initial delay [$ISECS]"
}
send () {
printf \\00\\00\\00\\00\\xa0\\00\\00\\00%159s\\00\\00\\00\\00\\n "$1" \
>&$OF || exit 1
}
changebutton () {
send "SendToModule '$MODULE' ChangeButton $1"
}
update_proc () {
CMAX=-1
PMAX=-1
NMAP=""
IS_FIRST=1
ps -A --format "%C %P %c" | while read C P N; do
# skip header
test $IS_FIRST = 1 && IS_FIRST=0 && continue
test $[CMAX < C] = 1 && CMAX="$C" && PMAX="$P" && NMAX="$N"
done
changebutton "'$IDPROC' Title '$PMAX $CMAX% $NMAX'"
}
update_clock () {
T=`strftime '%R %a %d.%m.' $EPOCHSECONDS`
changebutton "'$IDCLOCK' Title '$T'"
}
#
# parse options
#
if test $# -le 4 && echo "fvwm_periodic must be started by fvwm" 1>&2 && exit 1
OF="$1"
IF="$2"
shift 5
while test ! $# = 0; do
case "$1" in
-h|-\?|--help)
usage
exit 0
;;
-c|--clock)
test $# = 1 && usage && exit 1
shift
IDCLOCK="$1"
test ! x"$IDCLOCK" = x && zmodload zsh/datetime
;;
-t|--topproc)
test $# = 1 && usage && exit 1
shift
IDPROC="$1"
;;
-m|--module-name)
test $# = 1 && usage && exit 1
shift
MODULE="$1"
test x"$MODULE" = x && usage && exit 1
;;
-u|--update-secs)
test $# = 1 && usage && exit 1
shift
SECS="$1"
SECS="$[SECS]"
test "$[SECS]" -le 0 && usage && exit 1
;;
-d|--delay-secs)
test $# = 1 && usage && exit 1
shift
ISECS="$1"
ISECS="$[ISECS]"
test "$[ISECS]" -le 0 && usage && exit 1
;;
**)
break
;;
esac
shift
done
test $# -gt 1 && usage && echo "error: unknown option $1" && exit 1
#
# main body
#
trap exit HUP INT QUIT KILL PIPE TERM
# sleep is not a builtin, so prefer zselect
repeat $[ISECS]; zselect -t 100
while true; do
test ! x"$IDCLOCK" = x && update_clock
test ! x"$IDPROC" = x && update_proc
repeat $[SECS]; zselect -t 100
done
signature.asc
Description: Digital signature
