Skip to content
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

Should commands that are no-ops return a non-zero exit code? #187

Closed
dominiklohmann opened this issue Aug 3, 2019 · 5 comments
Closed
Labels
suggestion Request for new feature or some form of enhancement

Comments

@dominiklohmann
Copy link
Collaborator

Discussion

This was brought up by @kiryph in #186 (comment).

However, the exit code of yabai -m window --swap largest; echo $? is always zero, even when no swapping occurs (e.g. terminal window is the largest window where I execute this command).

Is this intentional?

I am really unsure about this and want to discuss a possible change here.

This affects the focus, swap and warp commands. Note that the focus command can also be used for its side-effect of raising an already focused window that was not raised (e.g. from ffm set to autofocus), so it's not really a no-op sometimes.

@kiryph
Copy link

kiryph commented Aug 3, 2019

Just another confirmation that the swap command with the window itself returns the exit code 0:

$ yabai -m window --swap $(yabai -m query --windows --window | jq -r '.id'); echo $?
0

The original intention was if swapping 'fails' the last swap is repeated.

@koekeishiya koekeishiya added discussion Discussion suggestion Request for new feature or some form of enhancement labels Sep 3, 2019
@koekeishiya
Copy link
Owner

I think this makes sense for swap and warp commands, but not necessarily for focus commands as they have a potential sideeffect of raising the window, as mentioned in the original post. I'll probably do an overhaul of the exit codes for all commands when I have time.

My focus is currently on making the current functionality more robust, and to make sure the interface is good and clean, before looking at adding any kinds of major new functionality.

@fenduru
Copy link

fenduru commented Mar 13, 2020

This would be really helpful for "resize" as well (for BSP layouts). I'm a BSPWM user trying to replicate my setup, and I'm really fond of being able to fallback when resizing. For instance I have hotkeys that will grow the window to the right, but if it can't (i.e. it's against the edge) fall back to shrinking from the left. Without this there's no way to have a hotkey that always grows/shrinks a window.

@MyopicPaideia
Copy link

This would be really helpful for "resize" as well (for BSP layouts). I'm a BSPWM user trying to replicate my setup, and I'm really fond of being able to fallback when resizing. For instance I have hotkeys that will grow the window to the right, but if it can't (i.e. it's against the edge) fall back to shrinking from the left. Without this there's no way to have a hotkey that always grows/shrinks a window.

I have set an alternate key binding for shrinking (meh + jikl) and growing (hyper + jikl) in BSP layout. It works well and avoids this particular case of the non-zero exit code. Yabai won't be able to be a direct replication of BSP - it is absolutely a lifesaver as a legitimate twm for macOS which we otherwise wouldn't have.

@dominiklohmann dominiklohmann changed the title Should commands that are no-ops should return a non-zero exit code? Should commands that are no-ops return a non-zero exit code? Mar 14, 2020
koekeishiya added a commit that referenced this issue Apr 2, 2020
@koekeishiya
Copy link
Owner

koekeishiya commented Apr 2, 2020

window swap, warp, insertion, grid, move, resize, and ratio,

space balance, mirror, rotate, set padding, set gap, toggle padding and toggle gap,

will now also report a non-zero exit code upon failure.

koekeishiya added a commit that referenced this issue Apr 2, 2020
@koekeishiya koekeishiya added addressed on master; not released Fixed upstream, but not yet released and removed discussion Discussion labels Apr 2, 2020
@koekeishiya koekeishiya removed the addressed on master; not released Fixed upstream, but not yet released label Apr 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion Request for new feature or some form of enhancement
Projects
None yet
Development

No branches or pull requests

5 participants