Redirect Output in the Middle of a Program??

[J. Collier]

Mike McNamara (mac at 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 at cantuar.uucp) and I discussed a scheme for this 
with Robert Elz (kre at 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 at lll-lcc.ARPA
>   
-------------------------
James Collier              Internet(ish):  james at cantuar.uucp
Computer Science Dept.,    UUCP:           {watmath,munnari,mcvax}!cantuar!james
University of Canterbury,  Spearnet/Janet: j.collier at nz.ac.canty (unreliable)
Christchurch, New Zealand. Office: +64 3 482 009 x8356  Home: +64 3 554 025