Live data from Hacker News

Sequential and parallel execution of long-running shell commands

github.com

11–20 of 50 posts

Re: Sequential and parallel execution of long-running shell commands

#11
I've wanted to write something like this for years! For me it's always long running rsync commands I want to chain.

I still might write one as it would be a fun way to play around with some low level code, but when I actually want to get things done I'll be checking this out.

Re: Sequential and parallel execution of long-running shell commands

#14
post #6
post #3

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?

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 focus of pueue lies on human interaction.

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

Re: Sequential and parallel execution of long-running shell commands

#15
post #12

I usually just need to run one big interactive job on a server, in which case I just do tmux my-command Ctrl-b d (detach) logout, go to bed, sleep, whatever log back into the server, tmux attach Would there be an advantage to using this over that?

Probably not in practice. You do save that ctrl-b keypress tho.

Re: Sequential and parallel execution of long-running shell commands

#17
post #16

Under "Features": >Pause/resume tasks, when you need some processing power right NOW! How is the pause and resume done?

> How is the pause and resume done?

Perhaps by sending SIGSTOP and SIGCONT, much like hitting Ctrl+Z on the console and later running bg or fg .

Note that this is not the same as Ctrl+S & Ctrl+Q on the console – that just pauses the output display not the process (though the process may subsequently pause if a buffer somewhere down the pipeline becomes full due to the terminal output pausing).

Re: Sequential and parallel execution of long-running shell commands

#18
post #12

I usually just need to run one big interactive job on a server, in which case I just do tmux my-command Ctrl-b d (detach) logout, go to bed, sleep, whatever log back into the server, tmux attach Would there be an advantage to using this over that?

Nope. Pueue is designed to handle your usecase times 5+.

I'm still using it for your usecase, as I'm already used to the interface by now :D.

Re: Sequential and parallel execution of long-running shell commands

#19
post #16

Under "Features": >Pause/resume tasks, when you need some processing power right NOW! How is the pause and resume done?

> How is the pause and resume done? Perhaps by sending SIGSTOP and SIGCONT, much like hitting Ctrl+Z on the console and later running bg or fg . Note that this is not the same as Ctrl+S & Ctrl+Q on the console – that just pauses the output display not the process (though the process may subsequently pause if a buffer somewhere down the pipeline becomes full due to the terminal output pausing).

Thanks.

Re: Sequential and parallel execution of long-running shell commands

#20
post #12

I usually just need to run one big interactive job on a server, in which case I just do tmux my-command Ctrl-b d (detach) logout, go to bed, sleep, whatever log back into the server, tmux attach Would there be an advantage to using this over that?

Your usecase reminds me of GNU screen
Post reply on HN