this post was submitted on 19 Mar 2025
19 points (100.0% liked)

Programming

19122 readers
88 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 2 years ago
MODERATORS
 

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 or mv
  • We don't want to inhibit when running stuff like htop, less, watch
top 8 comments
sorted by: hot top controversial new old
[–] pelya@lemmy.world 13 points 4 days ago (1 children)

We want to inhibit when running stuff like pacman, wget, cp or mv

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.

[–] ulterno@programming.dev 1 points 2 days ago* (last edited 2 days ago)

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).

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.


to scan your system for active TCP connections

I was thinking in similar lines. Just need to decide what cases are worth keeping on for.
e.g.

  • You may not want to inhibit sleep just for an idle ssh in a terminal.
  • You may want to inhibit in case you are encoding a video using ffmpeg. (in case of GUI programs, they are pretty full of stuff and I would expect them to inhibit when encoding)
[–] Kissaki@programming.dev 4 points 4 days ago

It can't be the terminal that decides what inhibits and what doesn't. It must be the user or programs themselves.

How would implementing it in the terminal rather than shell look like? As a user choice? I don't see how that's reasonably possible.

Reading the other comments it seems like there's already inhibit commands.

If the shell does not provide a command or alias, or they can't because the inhibit API is system dependent, it's on the user to define. The user could define a fg alias or command, fg for foreground, which executes the command with inhibition.

[–] Paradox@lemdro.id 3 points 4 days ago

MacOS has had caffeinate forever, and it works great

[–] Corngood@lemmy.ml 3 points 4 days ago

I use gnome-session-inhibit quite a bit, but it's hard to imagine a good way to automate it.

Sometimes I inhibit idle to keep something on screen, and sometimes I just inhibit suspend so something can complete.

It probably doesn't make sense for the terminal to have anything more than a protocol to control it. The only real benefit to that would be in remote sessions, and it's not really clear how it should work when multiple machines are involved.

[–] solrize@lemmy.world 2 points 4 days ago (2 children)

I remember writing a script that posted an X event 1x a minute for something like that. The event was probably simulating pressing the shift key.

[–] take6056@feddit.nl 4 points 4 days ago

I stIll use tHis methOd, it worKs flawleSsly!

[–] ulterno@programming.dev 0 points 2 days ago

It shouldn't be required on systems that support the corresponding FDO spec, but I guess, that would be done when that was not implemented.