Job Control Wishlist

[mrose.uci-750a%rand-relay at sri-unix.UUCP]

From:  Marshall Rose <mrose.uci-750a at rand-relay>

    We're running BSD 4.1a (yes, I know 4.2 is here, give us time), and
    there are times that I'd like to take a job and re-direct its i/o
    somewhere else.  For instance, it would be nice to be able to tell
    csh

	%1 > file &

    to direct the output of job 1 to the file and put it in the
    background.  I often have the inclination to do this when I start a
    command which I think is going to a) run fast or b) produce little
    output, and I don't re-direct the output.  Since I run with ``stty
    tostop'' set to prevent my screen from getting clobbered, this
    means that I usually interrupt the command and start it again, with
    re-direction in the background.  It could very well be that this
    problem is just an artifact of my style, so you may not find this
    very useful to you.

    In any event 4.1BSD won't let you do this, and I think it unlikely
    that 4.2 has it.  If 4.2 does have this, then don't read the rest
    of this message, just send me a message saying so.

    If not, it seems to me we need a dup3() call.  The call

	dup3(pid1, fd1, pid2, fd2)

    would perform a dup2() from pid1's fd1 to pid2's fd2.  Obviously,
    pid1 and pid2 must exist (you could default a 0 for your
    process-id); the process executing dup3() must have the same
    effective user-ids as pid1 and pid2; fd1 must be a valid
    file-descriptor for pid1; etc., etc.  Hence dup2(fd1, fd2) is
    really dup3(0, fd1, 0, fd2).

    Has anyone thought about this, or actually implemented this
    (optimistic, aren't I?) or something similar?

/mtr

    PS - the possibilities are limitless.  Think of all the times you
    wanted to have something go to more after you invoked it.  With
    dup3() you could use

	%1 | more

    and *poof*: csh would fork, the child would do the dup3() required
    to bind %1's stdout to its stdin, and then exec() more.  Wow.