3 ms·
There was some discussion on the NetBSD list today as to how you might do this properly, ie with OS support not some hacks [1]. Although it is not clear it is w
by justincormack 12y ago
There was some discussion on the NetBSD list today as to how you might do this properly, ie with OS support not some hacks [1]. Although it is not clear it is worth bothering, as you just use screen first...
[1] http://blog.gmane.org/gmane.os.netbsd.devel.kernel http://blog.gmane.org/gmane.os.netbsd.devel.kernel
- pmoriarty 12y agoThis is useful for those cases where you didn't start screen first, such as when you either forgot or didn't think you'd need it but it turned out you did.
- pronoiac 12y agoThis may be a dumb question, but wouldn't this work? * press ctrl-z to put the program in the background * start screen * run fg within screen
- caipre 12y agoscreen (and tmux) start a new instance of the shell, which would have no knowledge of the backgrounded process. You'd just see the message "fg: no current job"
- emmelaich 12y agoAnd even if you could(1), the background process typically has the terminal open - and screen uses a separate pseudo terminal aka pty -- As suggested by the name - rePTYr (1) ^Z sends SIGSTOP; to continue you can signal SIGCONT. But then what?!
- deleted 12y ago[deleted]
- anaphor 12y agoI just alias my terminal shortcut/command to start screen/tmux every time
- chrisseaton 12y agoDoesn't using screen have some drawbacks? For example it breaks native scrolling in the OS X terminal app, so I wouldn't want to run screen unless I really needed it.
- anaphor 12y agoYeah I don't know. I only mentioned screen to be fair. I use tmux and I don't usually have any problems, although I get problems when I use it with mosh sometimes (particularly weechat mouse support doesn't seem to work well).