Do You Understand Job Control in Bash? | Hacker News Reader

Do You Understand Job Control in Bash?

symkat.com

49 pointssymkat26 comments

    disown
 	
    disown [-ar] [-h] [jobspec ...]

    Without options, each jobspec is removed from the table of active jobs.
    If the `-h' option is given, the job is not removed from the table,
    but is marked so that SIGHUP is not sent to the job if the shell receives
    a SIGHUP. If jobspec is not present, and neither the `-a' nor `-r'
    option is supplied, the current job is used. If no jobspec is
    supplied, the `-a' option means to remove or mark all jobs; the `-r'
    option without a jobspec argument restricts operation to running jobs.

The important part:

That means...

    $ ./some_really_long_process
    (crud... I forgot to open GNU Screen first!)
    ^Z
    [1]+ Stopped
    $ bg
    [1]+ ./some_really_long_process &
    $ disown
    $ pgrep some_really_long_process
    12349
    $ logout

Now, log in again...

    $ pgrep some_really_long_process
    12349

I do not know of a way to "reclaim" a disowned process, though.

> I do not know of a way to "reclaim" a disowned process, though.

http://caca.zoy.org/wiki/neercs

Maybe someone can rip out the relevant parts and create "reattach" and get it in coreutils :)

I'll have to try this.

I have tried http://pasky.or.cz/~pasky/dev/retty/ before, with limited success. It would reattach a terminal running vim, but not Matlab, and was generally a bit flakey.

EDIT: I have now tried neercs. Like retty, vim can be stolen but attempting to steal zsh shell or Matlab sessions causes crashes.

I was once told VMS used to have decent native support for reattaching terminals? It's frustrating that we don't have this ability (at least not seemlessly) now.

There was a project to make screen easier to use, integrating it with gnome-terminal: http://monia.wordpress.com/2006/08/31/integrating-gnome-term... but the patches were never accepted.

The title of the blog post is "Understanding Job Control In Bash" -- why not submit it here under that same title?

Why would I want to use job control when I can use screen instead?

Why use the command line at all when you can use a GUI?

Understanding how your system works is a different level from choosing the tools in the first place.

You may not always have your optimal tool set, such as when you're remoting into someone else's environment (common for sysadmins or contractors), or when you're stuck using someone else's computer rather than your own.

It depends on what you do, I suppose. If your work doesn't have a large command-line component, using the command line might be disruptive.

A large part of my job involves working with remote Linux servers, so I chose to invest time learning Linux command line tools and vim. Now I'm more productive in a terminal than in a GUI environment. I use common tools that are installed by default on Linux/Unix/OSX, so I can sit down anywhere and do my work, or SSH directly into my machine and have my exact work environment securely and without latency.

A command line is a poor mans gui.

A gui is a poor mans command line.

Whichever I'm using there are always aspects of the work that you could do better with the other.

Give me an example of something that you could do better with a gui. Just curious.

Selecting a number of unrelated items from a list. Example: You have a folder with music files and want to select some to copy onto your portable music player. It's easier to click on the items to select them than typing all the names, even with file name completion.

- interactively increasing the contrast of an image

- browsing the web (sorry, lynx users)

- play games (not that I'm a gamer)

- desk-top publishing

- routing a PCB

- CAD

and so on...

But then, each of those has moments when you think to yourself 'Man, I wished I could script this' (well, maybe not the games).

Sure, but given that I already use screen, what use cases would I find easier using job control instead of plain screen?

Simple command line timer:

    remind() {
        [[ $# -ge 2 ]] || { echo >&2 "Usage: $FUNCNAME time msg"; return 1; }
        local sec="$(($1*60))"
        (   trap "echo \"\$sec seconds left\"" QUIT
            while ((--sec > 0)); do sleep 1; done
            say "${@:2}" # OS X only, replace with your favorite notifier
        ) 2>/dev/null &
    }

    $ remind 30 get the laundry

Query time remaining with kill -QUIT %jobspec. Good for systems that don't have at(1).

Thanks, that's useful!

Favorite notifier:

  echo "${@:2}" | growlnotify -t Reminder -s -m -

Hm. That looks like quite a typing exercise. What's wrong with:

    ( sleep 1800 ; say "get the laundry" )&

His can be added to your .bashrc/.bash_profile, and then all you have to type is:

  remind [minutes] [message]

Functions can be imported to your shell. =)

neat trick

One thing I do a lot, inside of a screen session, is:

  $ cd workingdir
  $ vim conffile
  (edit, then within file press CTRL-Z, which suspends)
  $ start_program
  (notice errors or misbehaviours based on bad config)
  $ fg
  (edit config file some more, open different buffer)
  ** repeat untill things are happy **

This is a minimal use of job control, but it is nice.

Other uses include juggling several programs at once, sometimes screen gets too annoying for simple progress monitoring of several processes at once. (One window per command for say 20 commands, makes it difficult to switch through to find the one vim one, or the sql prompt... 3 on the other hand is fairly easy).

You can also use :!command to execute a command from within vim. This is handy to execute :!make for instance.

Actually in that case, just :make will suffice.

A lot of times yes, but others, the actions i simplify to "run process" are actually several commands based on output, to do things like verify side effects, etc. The scenario I describe is also very nice for developing shell scripts because of this.

You can also use :sh to get to a shell, then type exit to get back to Vim.

You may be on a machine that doesn't have screen installed and it may be quicker to use job control then install it. There is something to be said for travelling light.

Say you're already in a screen session on host A and SSH from inside that session to host B. You want to run multiple commands on host B, but you don't want to start a nested screen session.

What I don't understand is why it bloats the shell instead of just using the OS' tools.

    # kill -STOP $pid
    # kill -CONT $pid

in Plan9 we do: echo stop > /proc/$pid/note

When they copied the /proc file system into Linux they did a cack handed version (as expected) - "by amateurs, for amateurs" as Dave Presotto put it.

http://plan9.bell-labs.com/magic/man2html/3/proc

Reply on news.ycombinator.com