[racket] current-subprocess-custodian-mode

At Thu, 14 Feb 2013 13:42:38 +0000, Norman Gray wrote:
> (parameterize ((current-subprocess-custodian-mode #f))
>   [...])
> 
> I get an error "current-subprocess-custodian-mode: expects argument of type 
> <'interrupt, 'kill, or #f>; given: #f".

Repair pushed to the git repo. Thanks for that report!

> Now, some other experiments indicate that this won't do what I want anyway, 
> since (current-*-port) aren't file-stream-port? ports.

If you're running plain `racket', I'm not sure why the current ports
are non-file-stream ports.

> What I _want_ to do here is basically execv(3) vi from a Racket program.  I 
> can't find such a thing, and the above is an attempt to see how far I could get 
> using 'subprocess' (hoping the vi child would be left with the parent FDs still 
> attached to the terminal, and letting the parent terminate), but the limitation 
> to file-stream-port? suggests it's not intended for this, which doesn't 
> astonish me.  I can broadly see how a naive exec would cause trouble within a 
> system like racket, but is this in fact unsupported?  Or am I just missing it?

The `system' function uses threads as needed to pump from
non-file-stream ports to the subprocess, but probably that's not what
you want to run `vi'.

Getting the original stdin, stdout, and stderr is unsafe from Racket's
perspective (which wants to allow a program to control the ports that a
sandboxed program can reach, for example). You could use the FFI to get
those ports, though.

Finally, if you really want execv() in the sense of replacing the
program that runs in the current process at the OS level --- i.e.,
without a fork() first -- then there are even some issues with calling
execv() directly through the FFI: various extra file descriptors may be
open, and various signal handlers are installed and signal dispositions
changed. We could add an FFI-accessible way to generally clean up for
an execv(), though.