Does nohup allow attaching back to the session? That seems to be the primary use case of shpool.

No, it doesn't let you attach back, it just keeps a command going after you've disconnected your session. But if you have good logging that might be good enough.

Or use GDB to change stdin/stdout of the nohup'd process to the current shell!

like reptyr[1] or retty[2] does?

[1] https://github.com/nelhage/reptyr [2] https://github.com/lkundrak/retty

Probably!

lol!

Nohup still attaches to the terminal's stdin/out/err. If the process is known to be non-interactive, redirecting to log files should be sufficient (tail -f to "reattach"). If it does expect interaction, creating a fifo file to redirect stdin from should work, but I've never tested it.

nohub doesn't attach nor redirect the stdin/out/err, it intercepts the HUP signal that apps receive when their controlling TTYs are disconnected.

Implying "tail -f $LOGFILE" is akin to tmux reattaching to a console is a stretch.

The standard Unix version of nohup does in fact redirect the output/error streams if they would otherwise go to a terminal. https://pubs.opengroup.org/onlinepubs/009695299/utilities/no... / https://en.wikipedia.org/wiki/Nohup

As the sibling comments show, nohup does occasionally have sharp edges re: sharing/inheriting std* streams. I've also encountered inconsistencies when using nohup with lots of different users' shells (academics of wildly variable technical skill levels, shell environments/customizations, and opinionatedness levels): what, exactly, does it mean to be backgrounded per "&"? Does nohup+& sufficiently background all types of shell jobs (answer: no--and some of those jobs even make sense to use with nohup)? Can configs in {ba,z,da,k,fi}sh change the job control behavior so that "forgetting" jobs malfunctions under nohup (if that's possible, your users will do it, I've found--and then defend their bizarre choices until you give up and move on)?

In those cases, I've found dtach to be slightly more reliable than nohup. Frequently I'll try one and switch to the other. Less frequently, I'll correct users' configs/workflows that are necessitating the troubleshooting in the first place. Even less frequently, I'll dig into what was actually the issue :)

https://linux.die.net/man/1/dtach https://dtach.sourceforge.net/