On Thu, Aug 16, 2007 at 11:14:58AM +0200, Dominik Vogt wrote:
> 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.By the way, I really don't understand why anybody considers ListenOnlyModules a hack. Isn't it perfectly acceptable to write a module that does not want to take any input? Why is it bad if fvwm deos not send messages to certain modules? Of course, writing such a module as an architecture dependent zsh script *is* a hack, but that's the user's problem (i.e. mine), not fvwm's. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, dominik.vogt (at) gmx.de
signature.asc
Description: Digital signature
