Discussion:
FVWM: Extracting an Environment Variable from FVWM
m***@crosswire.com
2011-08-25 18:07:04 UTC
Permalink
Howdy,

I'd like to be able to read FVWM's environment variables from an outside
script. I can set variables with:

FvwmCommand Foo bar

And can pass through to another script by doing something like this:

FvwmCommand Test (EnvIsSet Foo) Exec somescript $[Foo]

But I want to be able to do set/get from the same script. Is there a
way to do this with one of the perl modules perhaps? I've looked at the
documentation for Fvwm::Module and Fvwm::Command and a few others and
haven't seen quite what I'm looking for yet.

I can make this work using the passthrough method above, forking and
read/writing a FIFO but that is really sloppy, and I'd rather not go in
that direction. The other option is use Fvwm::Module, but I'm not sure
that it will inherit the environment namespace of FVWM.

Any help appreciated.
Thanks in advance!
Matt
Thomas Adam
2011-08-25 18:24:23 UTC
Permalink
Post by m***@crosswire.com
Howdy,
I'd like to be able to read FVWM's environment variables from an outside
FvwmCommand Foo bar
No. You set them with:

FvwmCommand 'SetEnv FOO bar'
Post by m***@crosswire.com
FvwmCommand Test (EnvIsSet Foo) Exec somescript $[Foo]
But I want to be able to do set/get from the same script. Is there a
way to do this with one of the perl modules perhaps? I've looked at the
Because they're in FVWM's process space and not anything else, and you're
wanting to use them elsewhere, you can do nothing *but* ask FVWM about them.
Again, I would just use FvwmCommand to echo the appropriate environment
variable.

Alternatively, what's the problem you're trying to solve? Perhaps there's
an easier way, rather than relying on this rather bizarre solution to a
problem you've not (yet) stated.

-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
m***@crosswire.com
2011-08-26 14:09:35 UTC
Permalink
-------- Original Message --------
Subject: Re: FVWM: Extracting an Environment Variable from FVWM
Date: Thu, August 25, 2011 2:24 pm
Post by m***@crosswire.com
Howdy,
I'd like to be able to read FVWM's environment variables from an outside
FvwmCommand Foo bar
FvwmCommand 'SetEnv FOO bar'
Post by m***@crosswire.com
FvwmCommand Test (EnvIsSet Foo) Exec somescript $[Foo]
But I want to be able to do set/get from the same script. Is there a
way to do this with one of the perl modules perhaps? I've looked at the
Because they're in FVWM's process space and not anything else, and you're
wanting to use them elsewhere, you can do nothing *but* ask FVWM about them.
Again, I would just use FvwmCommand to echo the appropriate environment
variable.
Right, but I presume it is possible to export the namespace using perlxs
or something. Probably a PITA to do it, which is why I was hoping there
was some existing IPC way of getting access to FVWMs environment
variables. The alternative is either writing a patch, wrapping
FvwmCommand, or using something else even more kludgy.
Alternatively, what's the problem you're trying to solve? Perhaps there's
an easier way, rather than relying on this rather bizarre solution to a
problem you've not (yet) stated.
-- Thomas Adam
--
Not a problem so much as a feature. If I can read/write to FVWMs
environment space, I can use it for token passing between scripts.
Essentially it gives me a place to cache IPC data, so that programs
don't have to be running symultaneously in order to communicate with
eachother.

Obviously the ultimate evolution of something like this would be an FVWM
Module that embeds an instance of SQLite into the window manager. But
for the moment, I don't need that much state.

There are many potential applications for this: Network sychronization
for example, or embedding localized algorithms for window placement.
IMHO it just makes FVWM easier to extend.

As I said before: I'd rather not have to wrap FvwmCommand. So if there
is a programatic way of getting access to FVWM's environment variables
without spending a week doing it, I'm all ears.

Thanks in advance!
Matt
Thomas Adam
2011-08-26 14:23:55 UTC
Permalink
Hi,
Post by m***@crosswire.com
Not a problem so much as a feature. If I can read/write to FVWMs
environment space, I can use it for token passing between scripts.
You can -- although be extremely careful here. If you're using variables
for state which have to be modified/queried *externally* from FVWM, because
you have some idea that it's useful for something, you're already doing it
wrong from the outset, to be honest.

FVWM is not a database. It is not designed to act like one, nor will it
ever be extended in that way. Yes, setting state via SetEnv from within
FVWM, and then running FVWM-specific things (in say PipeRead, to access that
state) is acceptable, because often that's a means to an end to achieve
something in terms of window-placement, or reacting to certain events, etc.
But note that the communication is always only ever one-sided in this
example.
Post by m***@crosswire.com
Essentially it gives me a place to cache IPC data, so that programs
don't have to be running symultaneously in order to communicate with
eachother.
To achieve what? Can you give me a more concrete example of where two
programs need to communicate, and why FVWM would possibly ever be
responisble for maintaining that state?
Post by m***@crosswire.com
Obviously the ultimate evolution of something like this would be an FVWM
Module that embeds an instance of SQLite into the window manager. But
for the moment, I don't need that much state.
Absolutely not.

The "ultimate evolution" would be FvwmSocket. To make FvwmCommand
disappear, and to then have communication via a Socket to extract
information which FVWM has. Yes, you might then be able to abuse this for
your own nefarious purposes, but you've still not told me what it is you're
really trying to do.
Post by m***@crosswire.com
There are many potential applications for this: Network sychronization
for example, or embedding localized algorithms for window placement.
IMHO it just makes FVWM easier to extend.
This is typically done in the form of language-bindings, which FVWM already
has one of.
Post by m***@crosswire.com
As I said before: I'd rather not have to wrap FvwmCommand. So if there
is a programatic way of getting access to FVWM's environment variables
without spending a week doing it, I'm all ears.
At the moment there isn't -- and all FvwmCommand is doing is relaying your
commands via its own FIFO to FVWM.

If you can give more information about what it is you're doing, again, I'll
be able to be more specific.

-- Thomas Adam

Loading...