On Monday 21 April 2003 03:25, Mikhael Goikhman wrote:
> > Hm, don't you consider Perl a separate process? In addition, don't I
> > need environment variables to interface with perl?
>
> I mean that when you start one FvwmPerl process together with fvwm,
> there are 0 forks per line. And when you invoke PipeRead (i.e. /bin/sh)
> that then starts bash, printf and similar, there are 3 forks per line.
OK, here's a realization in Perl:
DestroyFunc Let
AddToFunc Let
+ I SendToModule FvwmPerl eval my $tmp = $1; command("SetEnv $0 $tmp");
Anyways, what's the disadvantage of creating other processes?
> > > FvwmPerl may also be used as a more powerful replacement for FvwmCpp
> > > and FvwmM4 using its -p (--preprocess) flag.
> >
> > To be honest, I don't like that preprocessing stuff. Some standard FVWM
> > expressions do always collide with the preprocessor.
>
> This is not the case with "FvwmPerl -p", there are no such collisions.
Ok, I see that Perl code is always included between %{ and }%. This indeed
makes this module much more appropriate for preprocessing than FvwmM4 and
FvwmCPP. There, in addition to name clashes, one has to adapt quoting and
this is extremely annoying.
> I think it is at least much more readable then your solution with bash
> and dozen of environment variables.
What you showed is preprocessing. As said in my original post, what I'm
after is realtime processing where I need several global variables anyways.
Concerning readability: I'm not a Perler and for me the code isn't very
readable at all. Many FVWM users probably prefer a solution where they can
do simple arithmetics without knowing Perl.
Felix
--
To contact me personally don't reply but send email to
felix DOT klee AT inka DOT de
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
