Bspwm: bspc returns the wrong errorcode if its stdout is closed after execution

[SeerLite]

How to reproduce

1. Create the following example.sh:

#!/bin/sh

sleep 5
bspc query -N -n .floating
notify-send "$?"

Note: It's gonna use notify-send to output the return code of bspc

1. Open two tiled terminals on a desktop. One is for the following step while the other one is the placeholder for when the first one is closed.

2. Inside bash (works on zsh too), run the following:

sh example.sh &! exit

Expected Behavior

notify-send sends out a notification titled "1", because the focused terminal is tiled and not floating.

What actually happens

The notification comes out with a "0". bspc should't depend on the status of its stdout/err to return the right code. This has been incredibly difficult to debug.

Why does this matter

bspc cannot be used for scripting reliably if it's not prepared for these kind of situations, even if they're rare.

I was testing some stuff with sxhkd by running it in the terminal, and then disowning the process. Everything worked fine until I closed the terminal, where a lot of my keybinds just failed/did the complete opposite thing they were supposed to do.

That's all
Thanks

[baskerville]

A simpler way to reproduce is bspc zzz >&-.

[emanuele6]

A simpler way to reproduce is bspc zzz >&-.

~What do you mean? That works correctly, no? I didn't notice any change in behaviour.~

EDIT: Oh, you meant bspc query -N -n .floating >&-. Yes, that was fixed by e13255e. But the problem described by @SeerLite was not fixed for some reason.
EDIT2: It's a bit weird though, but I guess ut makes sense:

$ bspc query -N -n .marked > /dev/null ; echo "$?"
1
$ bspc query -N -n .marked >&- ; echo "$?"
1
$ bspc query -N -n .floating > /dev/null ; echo "$?"
0
$ bspc query -N -n .floating >&- ; echo "$?"
141

---

@baskerville

This "bug" is that if you run that script from your shell as sh example.sh & in a terminal and you don't close the terminal, you'll recieve a notification containing "1".

But, if you run the script in the same way and then you close the terminal (or the tmux window or whatever) from which the shell is running, you'll receive a notification containing "0" instead of "1".

This was not fixes by e13255e.

[emanuele6]

video: https://youtu.be/ew0sn53sL4g

[baskerville]

A simpler way to reproduce is bspc zzz >&-.

~What do you mean? That works correctly, no? I didn't notice any change in behaviour.~

EDIT: Oh, you meant bspc query -N -n .floating >&-. Yes, that was fixed by e13255e.

No, I literally meant bspc zzz >&-: this should always fail.

But the problem described by @SeerLite was not fixed for some reason.

Confirmed: I was mislead by the title.

Unfortunately, the original problem will be hard to fix: bspc isn't receiving any POLLIN events under those conditions.

[SeerLite]

Hi, thanks for looking into this!

Confirmed: I was mislead by the title.

Whoops, I assumed the cause was stdout being closed because the terminal was closed too. I have no idea what the difference is.

Unfortunately, the original problem will be hard to fix: bspc isn't receiving any POLLIN events under those conditions.

I don't know how it all works so I can't comment on how hard it is to fix. However, I think the issue should be reopened for now since it's still unexpected behavior

Thanks again

[ortango]

would something like this work: proposed fix patch file?

(apologies for the indentation, didn't take into account which editor i was using until now)

the idea being that subscribes without a fifo_path will tell bspc it is okay to exit if stdout is closed.

---

OT: @emanuele6 re:exit code 141. check SIGPIPE. (it should sig pipe in the cases when stdout is closed && there is output)

[emanuele6]

OT: @emanuele6 re:exit code 141. check SIGPIPE. (it should sig pipe in the cases when stdout is closed && there is output)

Yeah, I know what that means; I just said that it felt weird getting that exit status only when there are results (you can tell if the query is successful even when the program fails), but it makes sense.

[emanuele6]

would something like this work: proposed fix patch file?

@ortango, ~I tested this patch and it didn't fix the issue.~
nevermind, I applied the patch incorrectly because I had some local changes that I forgot to stash. It looks like a pretty clean fix.

[SeerLite]

Hi, I recently found out bspc isn't the only binary that has this this problem. pidof, pgrep and some other builtin tools on my system react the same way when there's no stdout available.

Since a lot of binaries seem to do this, I doubt it's a universal bug that should just be fixed everywhere. And it's made me think that it was just me doing it all wrong in the first place and this can be seen as a non-issue. In which case, I want to say sorry (but still thank you!) to all of you for spending your time looking into this.

From now on I'll just be more careful when using shell &!/disown and the like.

I leave it to your judgement to decide if this is an issue or not.