On 8/16/07, Dominik Vogt <[EMAIL PROTECTED]> wrote:
> 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?
A couple of reasons for it to be within my definition of "hack":
1. Modules are supposed to work following a set of rules, and
ListenOnly modules break that set of rules. It may also prevent some
future beneficial changes to the module communication because
ListenOnly modules wouldn't work anymore.
2. It is a particular scratch for a particular itch: it is only useful
for zsh. Perl modules work with the perl fvwm lib, C modules should
work with the (hypothetical) C fvwm lib. Other shell's can't work with
this mechanism, so some other mechanism must be devised for them.
So what I propose is kind of a "universal scratch" for that same itch,
applied to all shells. It isn't working as supposed yet, but once it
is it makes no sense to support the two "scratches".
> 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.
It is if the users complain that they want the same facility for bash
:) I believe we can't have yet a third mechanism :P
Cheers,
Renato
