A person, on the Gnome Issue, suggested that terminals inhibit sleep when there is stuff running in them.
Continuing from that discussion, I am trying to understand, at which point it would be desirable to implement said inhibition - terminal emulator, the shell or the program itself
Additionally:
- We want to inhibit when running stuff like
pacman
,wget
,cp
ormv
- We don’t want to inhibit when running stuff like
htop
,less
,watch
There is already a separate
systemd-inhibit
command that does exactly what you need. Trust your users, they are capable of googling it (most of the time).Only pacman and wget will benefit from suspend inhibition, because it will prevent breaking network connections. cp and mv will resume working just fine even when you hibernated your laptop while cp was executing. And in that case it’s less bug-prone to scan your system for active TCP connections to external addresses instead of adding a hack wakelock inside your terminal or inside wget.
It is also a poor idea to mess up with system-wide settings from some command when the user does not expect it, you’ll likely to get a thousand invalid bug reports that sleep mode is broken when some service randomly decides to use wget to continuously read from local Unix socket.
Thanks for this. I now have an idea that would work at least for my case.
So, in case the user runs some long-running command and doesn’t remember to use
systemd-inhibit
, but then decides they should have done so (which seems like something that would happen to me a lot), there can be an option in the console to inhibit until the end of said process.Still, automates nothing though, so maybe that’s just upto aliases and stuff.
I was thinking in similar lines. Just need to decide what cases are worth keeping on for.
e.g.