Hi. is there any to use environment variable in window rules in config.h in DWM

[nitrogenxx]

Hi..
today i though i should change my all the application into environment variable and then use that environment variable thought out the system.. instead of hardcore the application name on 1000 different place

but when i try to configure the environment variable for window rules in the config.h
i am having some trouble

i tried many different method but non of then working
for example :

when i try to change my terminal into environment variable and then use that environment veritable in the window rules in config.h
by using this DWM patch environmentvars

i found this patch is not working for the window rules

#define TERMINAL_ENVVAR "TERMINAL" // use: terminalcmd

static const Rule rules[] = {

    /* class                            instance    title       tags mask   switchtag  iscentered   isfloating   monitor */
    { terminalcmd,                   NULL,     NULL,       1 << 1,          1,                     0,               0,                -1 },

    };

but this patch is only working for keybindings

      { MODKEY,                XK_c,             spawn,           {.v = terminalcmd} },

i think this patch is only designed to work with keybinding but with window rules
i tried same thing with multiple application but they are working for keybinding but not working for window rules

i tried many different method non of them are working for window rules like example :

static const Rule rules[] = {

    /* class                            instance    title       tags mask   switchtag  iscentered   isfloating   monitor */
    {  SHCMD("$TERMINAL"),  NULL,     NULL,       1 << 1,          1,                     0,               0,                -1 },
     {  $TERMINAL,           NULL,     NULL,       1 << 2,          1,                     0,               0,                -1 }

    };

I'm looking for the guidance how to use the environment variable for window rules
i will really appreciate your willingness to help or any inside possible 🙆

[bakkeby]

I saw your reddit posts and I do understand the underlying incentive which would be to be able to make changes without having to recompile dwm, or being able to use the same dwm binary on machines that have a different setup.

Trying to use environment variables for this purpose is a bad idea for several reasons.

The first is that more often than not there is no direct correlation between the window class and the name of the executable.

The second, and please excuse me if I am wrong with my assumption here, is that you do not have a good understanding of how environment variables work.

The third is that it would reduce readability of your rules, making it harder to work out what is going wrong when you run into issues.

The fourth is that maintaining these rules and environment variables may be more cumbersome than you imagine.

I can probably think of other reasons but I'll leave it at that.

---

Elaborating on the first issue.

In the reddit post the BROWSER environment variable was used as an example referring to firefox.

This would likely work on some systems because the window class of the browser is "firefox" while the executable binary is also "firefox". What you may find is that on some other systems the window class for this browser is "Firefox", which means that the
rule would not match.

Another example is the binary "google-chrome-stable" which has the window class of "Google-chrome" or the binary "brave" having the window class of "chromeapp".

---

Elaborating on the second issue.

I'd say that most people are introduced to environment variables via bash scripting and/or having to make changes to the PATH environment variable in ~/.bashrc.

As such it is easy to think of environment variables as global variables and that the environment is the operating system.

That is not actually how it works though.

Each process have their own environment.

You can have a look at the environment variables for dwm if you first look up the process ID either by using ps -ef and grepping for dwm or you can use pidof dwm.

Then you can inspect the /proc/<pid>/environ file, e.g.

$ cat /proc/$(pidof dwm)/environ | xargs -0 -n 1

What you may find is that there are less environment variables than you might expect.

When one process spawns another process then, unless steps are taken to circumvent it, the child process will inherit the environment of the parent process.

As such the environment that dwm will have depends on how it is started, e.g. via startx or a display manager. dwm is not run from bash so it won't have whatever is set in your ~/.bashrc for example.

To add environment variables that will be present for dwm again depends on how you start it, but one option may be your ~/.profile file.

You would also need to consider that in order to apply changes for environment variables then you may need to restart your computer.

---

When it comes to how you could achieve this technically then you would have to consider that the rules array can only contain data that is static at compile time. It can't have dynamic data that is not known when you compile.

So I think the best appoach would probably to have placeholder strings in the class instead, e.g. "%BROWSER%".

In the applyrules function we check the rule class like this:

&& (!r->class || strstr(class, r->class))

It would probably make sense to move this out to a new function that checks if the rule class matches any of the known placeholders then the window class is matched against the value of the corresponding environment variable, if present.

Overall I think your effort would be better spent on other approaches.