Path: utzoo!utgpu!water!watmath!cantuar!james From: james@cantuar.UUCP (J. Collier) Newsgroups: comp.unix.wizards Subject: Re: Redirect Output in the Middle of a Program?? Message-ID: <302@cantuar.UUCP> Date: 8 May 88 18:49:27 GMT References: <13085@brl-adm.ARPA> <3571@gryphon.CTS.COM> <2841@cvl.umd.edu> <62@denali.UUCP> <670@esl.UUCP> Reply-To: james@cantuar.UUCP (J. Collier) Distribution: world Organization: University of Canterbury, Christchurch, New Zealand Lines: 73 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. 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. Stdio buffering assumptions would also cause unnatural behaviour in many programs. 3) The system would have to assume that (fileno(stdin) == 0) etc. This is not guaranteed. 4) Implementing it would involve something like ptrace()'s hideous machinations to access the target process's u area. 5) Yet another context dependent, multiple-occurrence-significant signal. Robert Elz's advice was "do it right, or not at all". He also pointed out that ptrace()'s methods were neither philosophically sound nor suitable for contemplation as a Sunday afternoon hack. This seemed reason enough to can that system, so I then looked at putting switchable pipelines into a shell using pseudo-terminals. On reflection I concluded that the idea was grotesque. Nevertheless, there would be many uses for such a system. Apart from the two already mentioned, one advantage would be the ability to move a process group to a different terminal or window - although the latter can be built into the window manager. Quite often I wish there was some method of doing this for input as well - e.g. to provide a prologue for an interactive program. ("cat foo - | bar" is not as useful as it looks for reason (2) above; in frustration I have at times used pseudo-terminals or TIOCSTI to achieve the desired effect, but these are ugly solutions). I think some fairly radical alterations would be needed to implement this facility cleanly. On its own it wouldn't justify these alterations, but the main underlying problems are becoming painful in other respects and may be due for attention anyway. Another subject, another posting... >-- > Michael Mc Namara ESL Incorporated ARPA: mac%esl@lll-lcc.ARPA > ------------------------- James Collier Internet(ish): james@cantuar.uucp Computer Science Dept., UUCP: {watmath,munnari,mcvax}!cantuar!james University of Canterbury, Spearnet/Janet: j.collier@nz.ac.canty (unreliable) Christchurch, New Zealand. Office: +64 3 482 009 x8356 Home: +64 3 554 025