New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pkill -RTMIN
and nohup &
don't work correctly
#24
Comments
I've been using dwmblocks with signal and clickable blocks for some time now and the only reason that I'm not using dwmblocks-async is that I have the same problem as well: kill/pkill signalling dwmblocks isn't working within the scripts used in dwmblocks or if the scripts are called from dwmblocks scripts. Is there any known workarounds for this to work? Btw, I use Arch (pun intended). Thank you. |
in line 22, if i'm not correct it's not needed to send a signal to dwmblocks. it should already refresh upon clicking. |
Yes, you're correct. No need to signal when clicking or scrolling. Still, I don't know what's happening cause it refreshes to the second-to-last state, instead of the last one and if I manually send signal through a dwmblock script, it won't just work. But if I send it through terminal, it works. |
@yuandi42 About the And about your script I see many room of improvement, took me like 30 mins or more to get my music script done and reading |
@explosion-mental
|
I think this behaviour is related to me wrapping the block command inside and Therefore, the command "sb-music" actually ends up being executed as "echo $(sb-music)". The reason why I had to use the This was working fine, but this issue is a limitation that has risen with this approach. Sadly, time is not something I have currently to investigate this issue. Therefore PRs and suggestions are highly welcome. |
Oh yeah, forgot to mention I didn't use the My suggestion is to omit the echo macro and make a notice about blocks that don't output anything. In that case anyone could just do |
That's a workaround, but ideally, |
Another workaround is to have programs launched quietly in the script. For example, this prevents the block from being stalled: st -e ncmpcpp >/dev/null 2>&1 & |
Hey think I found out something more. For blocks that don't output anything the block will never be updated, say a block needs to fetch or wait for something before showing the info, so it Logic; Say
|
That's precisely the problem. The Currently, I just poll the block's pipe to see if any text has been pushed to it. But that doesn't work if the block doesn't output anything, which causes our I've been trying to think of other ways of detecting the exit of forks but nothing has come up. |
I think I have found a fix for this issue finally. It was pretty simple looking back at it. Anyhow, the fix is in the new-org branch. I was playing around with the build system and code organization, so haven't merged it to
|
Closing in favour of #45 |
Sorry to bother you again with stupid questions. Below is a clumsy shell script called
sb-mpd
, written by me to show mpd status:There may be some unicode characters display wrongly since I use nerd fonts.
The first problem I had encounter with is in the line 22
mpd && pkill -RTMIN+15 dwmblocks
. Ideally when I left click the block,mpd
should start then the block should refresh, and it work correctlly when I test the command in my terminal. However, when I try to left click the block, blocks doesn't refresh, still showing "NO MPD" (mpd
is actually launched though).Another problem is about command in the line 11
nohup setsid -f "$TERMINAL" -e ncmpcpp &
. In my view,ncmpcpp
would be launched independently so that the block can refresh or accept later click event. Well, it doesn't. Andhtop
tree shows that there is a child processecho $(sb-mpd)
hanging underdwmblocks
.I would appreciate for your anwser.
P.S.: obviously
setsid -f
doesn't work either.The text was updated successfully, but these errors were encountered: