anton@ucbvax.ARPA (Jeff Anton) (06/24/85)
In article <288@azure.UUCP> stevesu@azure.UUCP (Steve Summit) writes: >> 1) have a swapfd system call >> Usage: swapfd(fd1,proc,fd2) >> or possibly: swapfd(proc1,fd1,proc2,fd2) >> >> what this does, is makes procs (usually another process) fd2, to become >> my fd1, and my fd1 to become (point to a file structure) of procs fd2. > >I don't know if it's what the original submittor had in mind, but >the reason I've thought a call like this would be neat is because >you could use it to give a shell the ability to manipulate i/o >"after the fact," just like job control lets you manipulate >backgroundness/foregroundness "after the fact." Is that command >taking too long? Type control-Z and background it. Don't want >the output coming out asysynchronously? Well, I haven't thought >of a syntax, but the idea is that you want to reconnect the >standard output of the process to a file. It gets hard if the >process in question has played with its file descriptors, like >repoening file descriptor 1 as something else, or dup'ing file >descriptor 1 to some other file descriptor and then using it >there. It gets messy. It gets very messy very quickly. csh dups it's input and output descriptors to around 17 from 0,1,2. Simply assumeing 0,1,2 are stdin, stdout, and stderr is not the way to go. Also, if a process forks it's children will also need to be changed. I've worked on what I called 'deferred redirection' where you would be allowed to redirect a process group after it's started execution. I believe the most sensable solution is to allow the following call: changefds(pgrp, fd1, fd2) int pgrp, fd1, fd2; Change all occerences of file decriptors in process group pgrp that are decendants of fd1 to refer to the file fd2. Decendants of a file descriptor are dup's and a child's inherited descriptor. This can be implemented in the kernel easily by moveing the descriptors from the user structure to the process table. This call would allow a shell to change a commands input or output to a file instead of the default. However, the changes to csh were too tricky for a simple hack job. -- C knows no bounds. Jeff Anton U.C.Berkeley ucbvax!anton anton@berkeley.ARPA
faustus@ucbcad.UUCP (Wayne A. Christopher) (06/24/85)
> changefds(pgrp, fd1, fd2) > int pgrp, fd1, fd2; > > Change all occerences of file decriptors in process group pgrp > that are decendants of fd1 to refer to the file fd2. > Decendants of a file descriptor are dup's and a child's inherited > descriptor. > > This can be implemented in the kernel easily by moveing the > descriptors from the user structure to the process table. > This call would allow a shell to change a commands input or output > to a file instead of the default. However, the changes to csh > were too tricky for a simple hack job. In conjunction with this call, you need two others (which I've tried to implement but never quite got around to debugging) -- chtty(pgrp, ttyname) Changes the controlling tty of processes in pgrp to ttyname, opening it if necessary. chparent(pid, newparent) Changes the parent of pid to newparent. This second one is the most difficult, and I had to do something like add an extra flag to the wait structure, which indicated that the child had been stolen. In any case, with these three you could do quite a bit with process changing. Of course, it's not clear how much "in the spirit of UNIX" all this is, but... Wayne
jack@boring.UUCP (06/26/85)
It will get messy very soon. Besides the fact that you have no idea how often the receiving process has dup()ped the file descriptor you swapfd(), you should also send it a signal to tell it that you mucked around with his file descriptors (SIGSWAPFD?). Every program downto 'ls' looks at stdout to determine wether it is a terminal nowadays, so you'd better notify it if you change it's output. By the way, even if you do so, the program will have a hard time getting everything right. If you replace stdout by a file descriptor pointing to another terminal, it will have to reset the mode of the previous terminal (hoping it can find it...), if it was a terminal, and then set the mode of the new terminal, if it is a terminal.......... It *would* be nice, though, to have a nice and clean mechanism to say that you don't want the rest of the output of a command on the terminal but on a file, but the stress is on *nice and clean*. -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster.
stevesu@azure.UUCP (Steve Summit) (06/28/85)
> 1) have a swapfd system call > Usage: swapfd(fd1,proc,fd2) > or possibly: swapfd(proc1,fd1,proc2,fd2) > > what this does, is makes procs (usually another process) fd2, to become > my fd1, and my fd1 to become (point to a file structure) of procs fd2. I don't know if it's what the original submittor had in mind, but the reason I've thought a call like this would be neat is because you could use it to give a shell the ability to manipulate i/o "after the fact," just like job control lets you manipulate backgroundness/foregroundness "after the fact." Is that command taking too long? Type control-Z and background it. Don't want the output coming out asysynchronously? Well, I haven't thought of a syntax, but the idea is that you want to reconnect the standard output of the process to a file. It gets hard if the process in question has played with its file descriptors, like repoening file descriptor 1 as something else, or dup'ing file descriptor 1 to some other file descriptor and then using it there. It gets messy. Steve Summit tektronix!tekmdp!stevesu