Sequential and parallel execution of long-running shell commands
1–10 of 50 posts
Re: Sequential and parallel execution of long-running shell commands
#2This looks quite helpful actually. Thanks for sharing.
Re: Sequential and parallel execution of long-running shell commands
#3Actually 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?
Re: Sequential and parallel execution of long-running shell commands
#4If you see following error logs,
$ pueue Error: Couldn't find a configuration file. Did you start the daemon yet?
Run `pueued -d` first. I think this prompt should be printed on the screen the first time it runs, or automatically executed.
Re: Sequential and parallel execution of long-running shell commands
#5The title is unclear, it should include the tool name
Re: Sequential and parallel execution of long-running shell commands
#6Actually 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?
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!
Re: Sequential and parallel execution of long-running shell commands
#7I am planning to use this for my homemade system-wide update scripts -- that updates via the OS package manager, Golang tools, Rust tools, OCaml tools, NPM-managed tools, editor configs (NeoVim headless updating of plugins as well), and others.
Seems like it has everything I need, the most crucial ones being separate queues / worker pools (f.ex. I only want the tasks that might involve source compilation to be executed one after another on a separate queue, never in parallel).
Anybody knows a good alternative to `multitail`? Still haven't found any other tool that can track the output of several commands at the same time on a screen that's automatically split -- and subsequently the finished tasks get removed from view until only the last one remains, taking the entire screen, and then it says "Done, press Q to quit".
Re: Sequential and parallel execution of long-running shell commands
#8Actually 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?
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 us…
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.
Re: Sequential and parallel execution of long-running shell commands
#9Actually 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?
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...
Re: Sequential and parallel execution of long-running shell commands
#10This looks awesome and the README seems to undersell it. Would it be possible for you to put code examples all over the readme so we can see what you’re talking about without needing to dig into the codebase?