FVWM: A small issue with SetEnv

[Roman Grazhdan]

It's about FvwmPiazza again. At cruncbanglinux forums Thomas kindly
proposed to use

ModulePath +:$./modules

instead of

ModulePath /usr/lib/fvwm/2.6.4:$[FVWM_USERDIR]/modules

which looks pretty sane to me, the latter depends on fvwm version and is
anyway redundant.

But using the better variant does not work for me - module doesn't start
and here's what I get when I start it manually with FvwmConsole:

[fvwm][executeModule]: <<ERROR>> No such module 'FvwmPiazza' in
ModulePath '/usr/lib/fvwm/2.6.4:'/home/tartan/.fvwm'/modules'

What did I do wrong here? Another user from the same thread has
everything working just fine, I went back to what I had before Thomas'
correction.

[Viktor Griph]

Post by Roman Grazhdan
It's about FvwmPiazza again. At cruncbanglinux forums Thomas kindly
proposed to use
ModulePath +:$./modules
instead of
ModulePath /usr/lib/fvwm/2.6.4:$[FVWM_USERDIR]/modules
which looks pretty sane to me, the latter depends on fvwm version and is
anyway redundant.
But using the better variant does not work for me - module doesn't start
[fvwm][executeModule]: <<ERROR>> No such module 'FvwmPiazza' in
ModulePath '/usr/lib/fvwm/2.6.4:'/home/tartan/.fvwm'/modules'
What did I do wrong here? Another user from the same thread has
everything working just fine, I went back to what I had before Thomas'
correction.

It looks as if you triggered some kind of quoting of the variable. Is
the ModulePath part of a function, and not on its own line in the
config file?

/Viktor

[Jaimos F Skriletz]

Post by Roman Grazhdan
It's about FvwmPiazza again. At cruncbanglinux forums Thomas kindly
proposed to use
ModulePath +:$./modules

There is an extra dollar sign in your ModulePath (I think that is
causing your issues):

Also you have using ./modules this is a relative path, but this could
cause issues depending on the cwd at the time that path is used, best to
use full paths.

From the fvwm man page

The ModulePath may contain environment variables such as
$HOME (or
${HOME}). Further, a '+' in the path is expanded to the
previous
value of the path, allowing easy appending or prepending
to the path.

For example:

ModulePath ${HOME}/lib/fvwm/modules:+

So I think you want ModulePath +:${HOME}/modules/ Though I think the
example in the manpage is better since it makes your custom path be
first on the module list over the default (This is useful if you want to
patch/use a custom fvwm module that already has the same name in the
full path).

[r***@cloudcabin.org]

@Victor - no, it was standing on its own in a part of the file describing
env. vars

@Jaimos - I ended up with ModulePath +:$[FVWM_USERDIR]/modules, since
nothing else works and I hope that's good enough.

I had it working as it was anyway, but I'm going to publish the config, so
it shouldn't propagate stupidity... Well not too much. :)

[Thomas Adam]

Post by Roman Grazhdan
It's about FvwmPiazza again. At cruncbanglinux forums Thomas kindly
proposed to use
ModulePath +:$./modules
instead of
ModulePath /usr/lib/fvwm/2.6.4:$[FVWM_USERDIR]/modules
which looks pretty sane to me, the latter depends on fvwm version and is
anyway redundant.

The point was for "+" to be used -- nothing more. In the case of your
adding "/usr/lib/fvwm/2.6.4" there, that's already come from the
built-in value FVWM will have assigned at compilation anyway [1].

As far as "$." versus "$[FVWM_USERDIR]", the point wasn't for me to
have removed it -- rather that I didn't remember your example when I
was correcting your "+" mistake, just that I knew "modules/" was in
there somewhere.

Note that setting ModulePath is potentially still a bad thing to do,
when the Module command already takes an absolute file name as means
of opening a module.

Post by Roman Grazhdan
But using the better variant does not work for me - module doesn't start
[fvwm][executeModule]: <<ERROR>> No such module 'FvwmPiazza' in
ModulePath '/usr/lib/fvwm/2.6.4:'/home/tartan/.fvwm'/modules'
What did I do wrong here? Another user from the same thread has
everything working just fine, I went back to what I had before Thomas'
correction.

I'm going to commit a fix to CVS to correct this quoting problem.
There is one, at it happens when FVWM expands its variables. In
certain other contexts it makes sense. In this one, it does not, and
I know there's been talk at the expansion code learning syntactic
sugar for this -- but until then, I'll band-aid the thing.

-- Thomas Adam

[1] This point about "+" used after your additions is a nice idea,
but ultimately incorrect for any proper use of ordering. You
shouldn't be writing modules of the same name as the ones FVWM ship,
only to then rely on the search order of what's in the ModulePath.
That way leads to fail, and anyone doing that now will get bitten on
the arse if it ever changes. So don't do it.

[r***@cloudcabin.org]

Post by Thomas Adam
Note that setting ModulePath is potentially still a bad thing to do,
when the Module command already takes an absolute file name as means
of opening a module.

Hmm. I probably will use the full path then, thanks.

Post by Thomas Adam
[1] This point about "+" used after your additions is a nice idea,
but ultimately incorrect for any proper use of ordering. You
shouldn't be writing modules of the same name as the ones FVWM ship,
only to then rely on the search order of what's in the ModulePath.
That way leads to fail, and anyone doing that now will get bitten on
the arse if it ever changes. So don't do it.

Who would do that, I wonder.