Hacker News Reader

Comment by mmaunder | Hacker News Reader

Actually the new top comment blew me away. I'm in the 20 year veteran category and was also oblivious. Quoted:

disown - bash built in.

You know how you always start that mega long rsync in an ssh session from your laptop and then realize you have to go offline halfway through? You forgot to start it in screen or nohup, didn't you? You can pause it (ctrl+z), background it (bg), and then disown it so it is protected from SIGHUP when you quit your ssh session. Bash (and, to be fair, zsh and others have copied much of this) has some wonderful job control features most people are completely oblivious of - even veterans of 20 years.

View on HN

You will be pleased to know that there is a site full of little gems like this:

http://www.commandlinefu.com/commands/browse/sort-by-votes

Most of my time savers that I've never thought of were found there.

python -m SimpleHTTPServer

Love this one.

And for you crazy people on python3..

python3 -m http.server

    [ward@hathor ~]$ ls -l /usr/bin/python
    lrwxrwxrwx 1 root root 7 Sep  5 00:45 /usr/bin/python -> python3

Arch default

I think he covered Arch users when he said "crazy people" :)

disown is great. However, I don't know if it's possible to start up a new shell, then bring back that process to the foreground. 'jobs' will return no entries, and fg doesn't take a PID parameter. Any ideas? It would be brilliant if that were possible with bash alone.

reptyr: https://github.com/nelhage/reptyr is Linux specific & involves a fairly gruesome abuse of ptrace() to attach a running process to your current pty. It won't put the process in the shell jobs list though.

There's also retty: http://pasky.or.cz/dev/retty/ but again it's not a complete solution.

disown -h will (reportedly) keep it under job control.

True, but doesn't help if you've quit the shell & want to re-attach to the process after logging back in again :(

Screen is the only real answer, I've ever found.

There's also 'tmux':

http://tmux.sourceforge.net/

Which according to reports has the benefit of being maintainable.

GNU screen, which I love and use to obscene extents daily, has an exceptionally hairy codebase. That said, I've got to get my tmux on and learn how to do screen equivalents with it....

http://www.techrepublic.com/blog/opensource/is-tmux-the-gnu-...

I keep seeing people comment on the codebase of screen being bad vs tmux, but I'm not sure why that is an issue? Are there any features of screen missing that haven't been added to the codebase? The vertical split patch has been added a long while back, and even though I'm sure tmux has a smaller memory footprint, I've never had an occasion where screen has ever been an app I'm worried might impact my server memory usage.

Since it is installed for the most part everywhere I have no desire to switch to tmux.

I can think of a few.

If there are problems found with screen (and it's a widely used admin tool that may be left running on remote servers, hence a high-value attack vector), it's going to be harder to find and fix the problem.

If there are features to be added, they'll be harder to add to screen than tmux. Which means that with time, tmux stands a higher chance of becoming more featureful.

Both argue in favor of tmux in the long run, though there's no immediate need to ditch screen. As you note, screen's very widely available, which is a feature. Then again, so was telnet 10 years ago.

FWIW, I've switched to tmux but think tmux's implementation of split screen is broken and desperately miss screen's.

Screen lets each part of a split screen select a different existing window. Tmux makes both parts of a split part of a single window, so you can either have two things going in one split, or have something else going on in another window, but if you suddenly decide you want two existing windows side by side, you can't do it.

Yes. screen will not run in terminals with long names, like rxvt-unicode-256color. This is due to a fixed-length buffer for storing the terminal name. Simple solution: make the buffer bigger. I did that and submitted the patch to Debian and upstream, and last I looked, it was still broken. I switched to tmux and never looked back.

OK, I looked back and it's fixed now: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621804. 6 months is a long time to wait. (Not that I'm criticizing Debian. It would never be fixed if it wasn't for the distributions patching it.)

True, screen and screenlikes. I've never used tmux, mostly because screen just works well enough for me.

I'm still a die-hard (and vertical-split-patched) screen user, but it seems tmux is the only suggested alternative. The combination of the more orthogonal dvtm[1] (for window management) and dtach[2] (for screen's killer feature: detaching) is flexible and compelling and sadly doesn't seem to have been mentioned here.

I currently use dvtm to split terminals and connect to multiple screen sessions in a single window. The downside of dvtm is it takes the dwm[3] approach of using #defines rather than configuration files.

1. http://www.brain-dump.org/projects/dvtm/ 2. http://dtach.sourceforge.net/ 3. http://dwm.suckless.org/

The only solution I've seen is to start up gdb with the process and point the process's 0, 1 & 2 file descriptors to the shell's STDIN, STDOUT and STDERR, then detach the process and quit gdb.

I can't remember the exact details, but that should be enough to set you up for some googling.

'man bash' is pretty amazing the first time you actually read through it.

And when you're done with that, try 'man zsh'.

Didn't know about disown, I always just did an "exec $SHELL" in this case.

Could someone explain what this would accomplish? If you have to go offline you would still lose that session, no?

Reply on news.ycombinator.com