maart@cs.vu.nl (Maarten Litmaath) (05/11/88)
In article <302@cantuar.UUCP> james@cantuar.UUCP (J. Collier) writes: \Mike McNamara (mac@esl.UUCP) writes: \> I'd be more interested in a way I could type \> % make \> interesting lines from make.... \> ^Z \> % bg > make.out \[....] \> Any one done this? \ \ Robert Biddle (robert@cantuar.uucp) and I discussed a scheme for this \with Robert Elz (kre@munnari.oz) last year. We didn't follow it up for \several reasons. \ \ After toying with various signal+IPC schemes (this is a 4.3BSD site), \we decided that it would be preferable to avoid compiling the handling \mechanism into every program. We proposed a new system call: \ dup3(localfd, remotefd, pid) \which would replace the file descriptor 'remotefd' in the process 'pid' \with the descriptor 'localfd' from the calling process - perhaps sending \a warning signal at the same time (c.f. SIGWINCH - urk). \ \ Although this looked clean enough at first sight, we acknowledged \a few potential problems: \ \ 1) Security - it would probably be insufficient just to compare the \ effective uid's; there may be r/e/uid-swapping programs which \ rely on the fact that a given file descriptor refers to a known file. The solution is to not allow a file decriptor to be redirected unless a special system call has been invoked, like allow(fd); Programs written "the old way" won't get into trouble, new programs can specify which file decriptors could be redirected. \ 2) Device types - there are plenty of programs which modify their I/O \ behaviour on the basis of isatty(fileno(stdout)) etc. The most \ seriously (fatally?) affected interactive applications would \ probably be unlikely targets for re-direction, but new features which \ can cause core dumps on hitherto healthy programs are undesirable. Same solution. \ Stdio buffering assumptions would also cause unnatural behaviour in \ many programs. That's precisely what we want, not? It's up to the user to redirect fd's, accepting the consequence of losing some buffered data. \ \ 3) The system would have to assume that (fileno(stdin) == 0) etc. Why? \ This is not guaranteed. \ \ 4) Implementing it would involve something like ptrace()'s hideous \ machinations to access the target process's u area. Come on! The UNIX kernel data structures are ok enough to implement the dup3() system call. However, in general UNIX needs some fixing, I'll grant you that! Consider the mentioned ptrace() and the existence of unkillable processes from time to time... \ 5) Yet another context dependent, multiple-occurrence-significant signal. So what? \... -- South-Africa: |Maarten Litmaath @ Free U Amsterdam: revival of the Third Reich |maart@cs.vu.nl, mcvax!botter!ark!maart