Test for greater or equal?

Is there a way to convert this:


if [[ ${height} -ge 864 ]]
	echo '$[FVWM_USERDIR]/side-all-panels.config'
	echo Nop

to pure fvwm speech?

Something in the lines of a:

Test (EnvMatch vp.height >=864)

Which of course doesn’t work.

I am trying to rip out some of the bash snippets on my config to lighten it a bit.

Thanks in advance.


– Thomas Adam

Nice, I think it should. That would cut down the need for external checkers (i.e. bash) for simple things like comparing two numbers.

Do you think that the fvwm-workers mailing list would be willing to hear about a patch for this purpose? I have a working one for just this: “Test (EnvGreaterOrEqual var )”. And it works ok. I could implement the whole set (Greater, Lesser, LesserOrEqual) if the people in the list like the idea. Or if you’d like any better approach just let me know. I just think that that is the natural way to do it in fvwm, in the same way of EnvMatch.

I ask for your opinion/advise, Thomas, before polluting the workers list (this thread is here anyway) in case that something similar had already been discussed/proposed in the past.


Like everything else, it’s something that will happen someday, but not just yet. There are arguments for and against such an internal implementation.

I’d be interested in seeing what you’ve done, if only because you have to be careful where and how you’re doing it – and you’d certainly have to take into account expand_vars() for instance, which is quite tricky.

It has been discussed and proposed in the past, yes. If you want mentoring before you suggest anything on fvwm-workers, just ask.

– Thomas Adam

Ok, I am sure that if there is a reason it is good enough.

Actually I have no idea how expand_vars() works, I know -for now- very little about the fvwm internals, but I don’t think that such a function is that complex. My patch is based in a mod of the EnvMatch part, it’s just an easy hack, but it should wok as expected, it just atoi() the two strings, compare them (instead of matchWildcards’ing them), and returns the value like EnvMatch does, based on that comparisson. Fvwm decides if the condition is ok or not, and acts consequently.

So, for now, it should have exactly the same bugs than EnvMatch, no more, no less :slight_smile:

And with that I mean the vp.height issue, that arose a few days ago in the workers list :wink: In that thread of the list the main argument about removing variables with dots was that “who cares if it is the stuff outside fvwm which is broken?” but now it seems that the Test stuff -which is inside fvwm- is also broken cause of this dot thing. So I need to do things like:

SetEnv height $[vp.height]
Test (EnvMatch height <whatever>) Crap

Well, if you think that this feature would be usefull and that it does not break anything per sé, I would like to hear of any suggestion, correction or guidance that you can give me. I can always maintain it like a separate patch, but I think that there could be more users interested in this feature, and as the patch is right now, it should not break anything that is not already broken, like the dot thing explained above.

EDIT, ops! forgot to include the patch.

jesgue.homelinux.org/public/6thp … qual.patch

This is just for GreaterOrEqual, if you like it I will create the others.

Yes, I know. It was me who raised it.

This is exactly why it’s not as simple as you’ve just outlined.

It’s up to me as to whether it would be useful – I am not a developer of FVWM, anyway. Note that the “dot thing” is only broken when interpolation from the shell happens – FVWM (as mentioned via expand_vars() and friends) handles the cases of double interpolationg env vars with various characters in them, for instance.

I’ll by all means take a look at your patch, although do have a look at the fvwm-workers archives – I know it has been mentioned there before with various solutions/ideas. I can’t be bothered to look.

– Thomas Adam

I will, thanks for looking into the patch. I await suggestions if you have the time to give any, though, as already said, it is mostly copied from the stuff that was already present in conditional.c


EDIT, that was quick, I have another patch file with the rest of conditions here:

jesgue.homelinux.org/public/new- … ions.patch

They are EnvGreaterOrEqual, EnvGreater, EnvLesser and EnvLesser or equal. No instructions required, they all are based and works exactly like EnvMatch. No intensive tests have been done in those last three, but since they are copypasted all should work :stuck_out_tongue:

Also, note that the core of this is

                    match =          
                        /* include empty string case */
                        (!pattern[0] && !value[0])
                        (atoi(value) >= atoi(pattern));

This means that it works effectively with integers, I can’t see why anyone would compare the value of two strings in fvwm (other than what EnvMatch does), but if needed strcmp or a custom function, instead of that simple comparison. I just wanted to keep it easy and quick.

I think that this integrates ok with the way to work that EnvMatch does, and complements it. But that is just my opinion. I am looking at the threads in the workers list, but they start looking into this simple thing and end discussing about fvwm, I will continue digging, though.

There’s nothing wrong with it as such, although the entire:

if (whatever)
    match = (..) || .....
} else {
} else {

Sub-sections should probably go in a function of their own (I hate seeing enormous amounts of code embedded under things like repetitive if statements or case statements, for example). I don’t suggest you do this though given that hasn’t happend already.

What would be better is if you were to use the same options (in syntax) as how the test for Version strings happens. It’s much more natural to compare numbers in this way, frankly.

– Thomas Adam

I think the same, and did not touch it because the model (EnvMatch) is already that way, and I did not want to mess up with the code that’s already there.

No doubt, I also though of that, and will look into it.

Thank you, Thomas.

EDIT, I made another patch, it holds all the stuff in the previous one, and additionally a new syntax.

jesgue.homelinux.org/public/new- … s-v2.patch

Both ways works with that patch, you can do either of those (the commented one, or the uncommented one). They both do the same.

# Read the left side panels
# ONLY if your screen resolution is equal or above
# 864 pixels on height
#Test (EnvGreaterOrEqual height 864) Read $[FVWM_USERDIR]/side-all-panels.config
Test (Compare height >= 864) Read $[FVWM_USERDIR]/side-all-panels.config

The other operators are evident, but they are in the man page anyway, in case there is a need for clarification.


I forgot about this for a while, but I am here again.

I reviewed a couple of old threads in the mailing list about this. Well, really one thread, the other is just one post:

mail-archive.com/fvwm-worker … 00091.html
mail-archive.com/fvwm-worker … 13962.html

On the thread, Rafal Bisingier, Mikhael Goikhman, Scott Smedley and Uwe Pross discuse about the issue, but also about some more complex things, which are not intended to be on this simple patch. This is just intended to work as a simple Test modification, by reusing all what’s there, and not to provide any advanced conditional functionality.

So, Thomas, what do you think I should look into before submitting this to the workers list? I would like this to get upstream, I know it is not brilliant, but it is designed following the lines of the already present code for other Test conditions, mainly EnvMatch.

If you have some time and can provide some advice on what else to do (if anything) before tainting the fvwm-workers list, it would be helpful.

Thanks in advance for any help.

Well I do remember a long discussion about adding all sort of different things, but as it stands this seems to add most of the more likely candidates. Submit it, and see what response you get.

Good luck. :slight_smile:

– Thomas Adam

Thank you, Thomas. I will do it right now and will try to expose it in the most convenient way, and see if I get any feedback at all. :smiley:

Ummm, out of pure luck, today I noticed something strange. I posted this patch and another topic regarding an FvwmForm bug to this mail box:

To: Fvwm lists <fvwm-workers@lists.math.uh.edu>

Thomas, is that a right mailbox? I don’t remember where that mail came from. The mails I see in the list seems to be sent to mailto:fvwm-workers@fvwm.org, which is a different mail address. Mi mails ended here:

mail-archive.com/fvwm-worker … th.uh.edu/

What is the difference between those two? Maybe I am hitting an old -unused-server? The rest of mails I see in that list don’t seem to get piled in that place. Just those I sent to this “alternative” mailbox.

They’re the same address, one of them is simply an alias for the other. And yes, your emails have been getting through.

– Thomas Adam

Thanks, I felt curious about that two different names. Though I supposed one of them is just an alias, I figured that I’d better ask to make sure :slight_smile: