Hacker News Reader

Comment by elif | Hacker News Reader

Actually pretty sweet. `ps | grep` can be tricky to navigate sometimes. I know I've certainly grabbed the wrong process a few times.

I'm not exactly sure what advantage this has over managing `screen` sessions tho. Maybe it's cleaner from a process tree perspective?

View on HN

This question has been asked quite a lot, so I wrote a FAQ ;D :

https://github.com/Nukesor/pueue/wiki/FAQ#why-should-i-use-i...

I was about to write that this has a different use case, because managing screen/tmux sessions is very manual. However the repo iself states

> Pueue is not designed to be a programmable (scriptable) task scheduler/executor. The focus of pueue lies on human interaction.

So I also don't really see its usecase and probably would opt for tmux instead. If you had many workers to run, but still do it manually, you would use pueue? I would be interested in such a scenario!

The concurrency controls are not present using the tmux method. Though if I am running enough tasks for this to be an issue then something odd is happening.

The queue being persisted and surviving crashes could be useful, and isn't the case with tmux unless you manually script it up. Though it could be painful if the crash leaves things remaining tasks depend upon in an odd state…

The task tree could be useful: scheduling tasks to start once other tasks are completed.

You can do this in pure bash I believe. E.g. when you launch a command you can capture its pid then wait for that to exit as you expect before running further jobs.

>The focus of pueue lies on human interaction.

How is it better than me having another window open and running my long running command there?

Well, if you're planning on running 10 commands sequentially that might take a few hours each, you would have to keep those windows open for quite a while.

See https://github.com/Nukesor/pueue/wiki/FAQ#what-can-i-use-it-...

Reply on news.ycombinator.com