dwm quits as soon as I login.

[apoorv569]

I was trying to get rid of some patches in my build, so I decided to start from fresh, but because I didn't felt like patching so I went with the flexipatch. It was working fine until recently it suddenly crashed and threw me back to login manager. After some investigation it looks like dwmblocks is the culprit. But I cannot figure out why. Here is my patches.def.h file, had to rename it to .txt because github would not let me attach a .h file.

patches.def.h.txt

I also cloned the latest build of dwmblocks from - https://github.com/torrinfail/dwmblocks.git and patched it with this - https://dwm.suckless.org/patches/statuscmd/dwmblocks-statuscmd.diff

Here is the patched dwmblocks.c file

dwmblocks.c.txt

Here is a one of the scripts that I'm using, maybe the status2d patch is having problem with parsing something,

#!/bin/sh

case $BLOCK_BUTTON in
        1) setsid -f "st" -e htop ;;
        2) notify-send " Memory hogs" "$(ps axch -o cmd:15,%mem --sort=-%mem | head)" ;;
        3) notify-send "  Memory module" "\- Shows Memory Used.
- Click to open htop.
- Middle click to show memory hogs." ;;

esac
icon=""
#icon="🧠"

mem="$(free | awk '/^Mem: /{print int(($3 + $5)/1024)}')Mi"

printf "^c#d8a657^ $icon $mem^d^ ^c#4a4a4a^|^d^\n"

[bakkeby]

You have the BAR_COLOR_EMOJI_PATCH enabled, do you also have the libxft-bgra library installed that adds support for color emoji?

[apoorv569]

You have the BAR_COLOR_EMOJI_PATCH enabled, do you also have the libxft-bgra library installed that adds support for color emoji?

Yes, I have libxft-bgra installed from the AUR.

Also have these fonts set in the config.h

static const char *fonts[]               = { "FiraMono-Regular:pixelsize=12:antialias=true:autohint=true",
                                             "Mononoki Nerd Font:size=12:antialias=true:autohint=true",
                                             "JoyPixels:size=12:antialias=true:autohint=true",
                                             "Noto Fonts Emoji=12:antialias=true:autohint=true" };
static const char dmenufont[]            = "FiraMono-Regular:pixelsize=12:antialias=true:autohint=true";

And I also noticed, when it was working, clicking on the widgets, was not doing anything. But now I can't test it, because enabling dwmblocks crashes dwm.

[apoorv569]

Sorry, accidently closed the issue.

[bakkeby]

The status2d logic can be finicky when it comes to handling incomplete syntax.

In my experience this is not necessarily status2d that causes dwm to crash, but it is more often than not due to dwm exiting gracefully due to the die calls here: https://github.com/bakkeby/dwm-flexipatch/blob/0c88a49e27fd0888c81aea5dd3eef1c537164a6a/drw.c#L282-L310

Anyway, you are saying that you have multiple of these scripts yes?

While ^c#d8a657^ $icon $mem^d^ ^c#4a4a4a^|^d^ looks correct you could end up with ^c#d8a657^ $icon $mem^d^ ^c#4a4 if the combined string is cut off prematurely.

If you look in the dwmblocks.c there is this line that restricts the total width of the outputted string to 50:

#define CMDLENGTH       50

https://github.com/torrinfail/dwmblocks/blob/4c392c32ed90d6cee2f771664852179d225eedc9/dwmblocks.c#L17

Personally I'd set this to something larger (I have, or had, 2048 myself).

[apoorv569]

Anyway, you are saying that you have multiple of these scripts yes?

Yes.

While ^c#d8a657^ $icon $mem^d^ ^c#4a4a4a^|^d^ looks correct you could end up with ^c#d8a657^ $icon $mem^d^ ^c#4a4 if the combined string is cut off prematurely.

If you look in the dwmblocks.c there is this line that restricts the total width of the outputted string to 50:

#define CMDLENGTH     50

https://github.com/torrinfail/dwmblocks/blob/4c392c32ed90d6cee2f771664852179d225eedc9/dwmblocks.c#L17

Personally I'd set this to something larger (I have, or had, 2048 myself).

Ah! I forgot about this CMDLENGTH, I had this changed in the previous build as well. I think this fixed the crash, but the click actions are still not working, as you can see in the script that I shared, there mouse click actions defined, that worked in my previous build, but they are not working now.

[bakkeby]

What does your blocks.h config look like?

[apoorv569]

What does your blocks.h config look like?

❯ cat blocks.h
//Modify this file to change what commands output to your statusbar, and recompile using the make command.
static const Block blocks[] = {
   /*Icon*/                /*Command*/                       /*Update Interval*/  /*Update Signal*/
//    {"",        "~/.local/bin/statusbar/music",                      0,                 11},
    {"",        "~/.local/bin/statusbar/weather2",                   1800,              5},
    {"",        "~/.local/bin/statusbar/netspeed",                   5,                 4},
    {"",        "~/.local/bin/statusbar/cpu",                        1,                 13},
    {"",        "~/.local/bin/statusbar/memory",                     10,                14},
    {"",        "~/.local/bin/statusbar/cpu-temp",                   5,                 2},
//    {"",        "~/.local/bin/statusbar/gpu-temp",                   5,                 17},
//    {" ",      "xbacklight | sed 's/\\..*//'",                      0,                 15},
    {"",        "~/.local/bin/statusbar/brightness",                 0,                 15},
    {"",        "~/.local/bin/statusbar/volume",                     0,                 10},
    {"",        "~/.local/bin/statusbar/battery",                    5,                 3},
    {"",        "~/.local/bin/statusbar/webcam",                     1,                 6},
    {"",        "~/.local/bin/statusbar/microphone",                 1,                 8},
    {"",        "~/.local/bin/statusbar/usb",                        1,                 9},
    {"",        "~/.local/bin/statusbar/bluetooth",                  1,                 7},
    {"",        "~/.local/bin/statusbar/internet",                   1,                 12},
    {"",        "~/.local/bin/statusbar/pacupdate",                  18000,             16},
    {"",        "~/.local/bin/statusbar/clock",                      60,                1},
};

//sets delimeter between status commands. NULL character ('\0') means no delimeter.
static char delim[] = "\0";
static unsigned int delimLen = 5;

[bakkeby]

I think that should be fine, you may want to skip 10 as that would be rendered as a newline, but I don't think that should have that much of an impact. I can't spot any obvious reason why clicks won't work.

As an aside I used this pattern for handling updates and clicks in the same script.

#!/bin/sh
if [ -z $BLOCK_BUTTON ]; then
    echo "whatever the status shows by default"
    exit
fi

case $BLOCK_BUTTON in
    *) notify-send -t 2000 "handle button click for button $BLOCK_BUTTON" & ;;
esac

[apoorv569]

I think that should be fine, you may want to skip 10 as that would be rendered as a newline, but I don't think that should have that much of an impact. I can't spot any obvious reason why clicks won't work.

As an aside I used this pattern for handling updates and clicks in the same script.

#!/bin/sh
if [ -z $BLOCK_BUTTON ]; then
  echo "whatever the status shows by default"
  exit
fi

case $BLOCK_BUTTON in
  *) notify-send -t 2000 "handle button click for button $BLOCK_BUTTON" & ;;
esac

Strange but I noticed something, I changed my script to something like what you shared above,

❯ cat memory
#!/bin/sh

if [ -z $BLOCK_BUTTON ]; then
        echo "BLOCK BUTTON ECHOING OUT.."
else
        echo "ERROR, SOMETHING WRONG!"
        exit
fi

case $BLOCK_BUTTON in
#       1) setsid -f "st" -e htop ;;
        *) notify-send -t 2000 "handle button click for button $BLOCK_BUTTON" & ;;
#       2) notify-send " Memory hogs" "$(ps axch -o cmd:15,%mem --sort=-%mem | head)" ;;
#       3) notify-send "  Memory module" "\- Shows Memory Used.
#- Click to open htop.
#- Middle click to show memory hogs." ;;
esac

icon=""
#icon="🧠"

mem="$(free | awk '/^Mem: /{print int(($3 + $5)/1024)}')Mi"

printf "^c#d8a657^ $icon $mem^d^ ^c#4a4a4a^|^d^\n"

The click action was still not working, but when I added the else statement, it started working, but it also keeps showing notification after couple of seconds it self even if I don't click. And click action is only working for this script other modules don't work still.

[bakkeby]

Yes but that is just because when dwmblocks run the script to get to the very bottom it goes through that case statement where the BLOCK_BUTTON is an empty string. The if [ -z $BLOCK_BUTTON ]; then checks if the environment variable BLOCK_BUTTON is set, and if not it enters the if statement.

I'd have expected something like this:

#!/bin/sh

if [ -z $BLOCK_BUTTON ]; then
    icon=""
    #icon="🧠"

    mem="$(free | awk '/^Mem: /{print int(($3 + $5)/1024)}')Mi"

    printf "^c#d8a657^ $icon $mem^d^ ^c#4a4a4a^|^d^\n"
        exit
fi

case $BLOCK_BUTTON in
#       1) setsid -f "st" -e htop ;;
        *) notify-send -t 2000 "handle button click for button $BLOCK_BUTTON" & ;;
#       2) notify-send " Memory hogs" "$(ps axch -o cmd:15,%mem --sort=-%mem | head)" ;;
#       3) notify-send "  Memory module" "\- Shows Memory Used.
#- Click to open htop.
#- Middle click to show memory hogs." ;;
esac

Anyway, I think I worked out why clicks don't work for you anymore.

I think the patch must have changed because the patch for dwmblocks no longer sets the BLOCK_BUTTON environment variable, but the BUTTON environment variable.

So try your script again just replace BLOCK_BUTTON with BUTTON (or update your dwmblocks to set BLOCK_BUTTON instead of BUTTON).

$ grep -n BUTTON dwmblocks.c
73:                setenv("BUTTON", button, 1);
76:                unsetenv("BUTTON");

[apoorv569]

Yes but that is just because when dwmblocks run the script to get to the very bottom it goes through that case statement where the BLOCK_BUTTON is an empty string. The if [ -z $BLOCK_BUTTON ]; then checks if the environment variable BLOCK_BUTTON is set, and if not it enters the if statement.

I'd have expected something like this:

#!/bin/sh

if [ -z $BLOCK_BUTTON ]; then
  icon=""
  #icon="🧠"

  mem="$(free | awk '/^Mem: /{print int(($3 + $5)/1024)}')Mi"

  printf "^c#d8a657^ $icon $mem^d^ ^c#4a4a4a^|^d^\n"
        exit
fi

case $BLOCK_BUTTON in
#       1) setsid -f "st" -e htop ;;
        *) notify-send -t 2000 "handle button click for button $BLOCK_BUTTON" & ;;
#       2) notify-send " Memory hogs" "$(ps axch -o cmd:15,%mem --sort=-%mem | head)" ;;
#       3) notify-send "  Memory module" "\- Shows Memory Used.
#- Click to open htop.
#- Middle click to show memory hogs." ;;
esac

Yes, I was just testing if it helps.

Anyway, I think I worked out why clicks don't work for you anymore.

I think the patch must have changed because the patch for dwmblocks no longer sets the BLOCK_BUTTON environment variable, but the BUTTON environment variable.

So try your script again just replace BLOCK_BUTTON with BUTTON (or update your dwmblocks to set BLOCK_BUTTON instead of BUTTON).

$ grep -n BUTTON dwmblocks.c
73:                setenv("BUTTON", button, 1);
76:                unsetenv("BUTTON");

I see, I changed the variable, it is working now, but as soon I click on it, say I right click, it shows the notification and memory widget itself disappears from the bar for few seconds, then comes back.

This is only happening with the memory widget, other widgets are working fine, only the memory script I changed with the if else statement you shared, could it be because of that?

[bakkeby]

Ah, the thick plottens. I have always wondered about that and I have never figured out why that is. It never happened that frequently for me so I never investigated it.

I presume that you are using the pattern I proposed.

I suspect that the pattern is wrong and what you had before was more correct. I think the very same mechanism for updating the "block" is being reused for the clicks, meaning that when you click on a block it still expects an output even if it hasn't changed. It's a bit of an odd way of doing it. I would have thought the two would be more independent of each other, but it explains odd behaviour like that.

[apoorv569]

Ah, the thick plottens. I have always wondered about that and I have never figured out why that is. It never happened that frequently for me so I never investigated it.

I presume that you are using the pattern I proposed.

I suspect that the pattern is wrong and what you had before was more correct. I think the very same mechanism for updating the "block" is being reused for the clicks, meaning that when you click on a block it still expects an output even if it hasn't changed. It's a bit of an odd way of doing it. I would have thought the two would be more independent of each other, but it explains odd behaviour like that.

I see, I will revert the changes then I guess.

Thanks! I guess the issue is solved, I'm closing the issue now.