-
Notifications
You must be signed in to change notification settings - Fork 50
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
[feature req] Accept more inputs? #129
Comments
Why is it a problem that wob exits on invalid input? My use-case is that I first try if the script piping into wob works and then include it in service manager / sway config / whatever. And once the script works, it shouldn't really randomly break. |
This is true! My main idea is to make scripting easier, e.g. in sway/config. It's helped me make some toggles neater, because now a As for the inputs, current wob is fragile but always correct, my proposed wob is robust but might silently coerce bad input. As you say it will only make a difference if underlying tools change, anyway. I've made a wrapper script that implements this, for my own use. Just thought it might be useful to others :) It's just an idea, if you're happy with current wob, so am I -- you've made something really useful 😊 thank you! |
I would also really prefer wob to not exit on invalid input. Although I do test my scripts it (surprisingly) sometime happens that I miss something and then wob is killed for the session, forcing to either start it manually or restart the whole session for further debugging. Finally, I don't see how wob exiting is a useful feature in itself, but maybe I am missing some use case |
It would be good to accept more input without crashing, and make it slightly simpler to script with
wob
. I'd suggest:0
, soecho | wob
would work, (and commands with empty output, too)grep | wob
without needingsed
etc.The downside of adding these behaviours is that it would be difficult or impossible to add other valid input types in the future, at least without ambiguity. Although I don't think that would be very useful, unless you wanted to accept config changes or commands.
Separate/related thought - Exiting on invalid input isn't particularly helpful anyway, I think I'd prefer that it responds as best it can and keeps running.
The text was updated successfully, but these errors were encountered: