[racket] current-subprocess-custodian-mode

Matthew, hello.

On 2013 Feb 15, at 00:30, Matthew Flatt wrote:

> 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!

A pleasure.

>> 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.

Doh!  I was doing this as a quick between-students experiment.  Exploration, rather than development, I tend to do in DrRacket, so...  That _really_ should have occurred to me.

>> What I _want_ to do here is basically execv(3) vi from a Racket program.
>> [...]
> 
> 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.

That's more than I'd want to get involved with in this case, for what is basically a quick utility program.

The following appears to work as well as required.

(define (edit-file/subprocess fn)
  (receive (process stdout stdin stderr)
      (subprocess (current-output-port)
                  (current-input-port)
                  (current-error-port)
                  "/usr/bin/vi"
                  fn)
    (subprocess-wait process)
    (eprintf "child pid=~a~%exiting...~%" (subprocess-pid process))))

> 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.

I've just found <http://docs.racket-lang.org/inside/Subprocesses.html>, which explains this in some detail.  Thanks for the overview.

Don't add anything on my account: the above works for me (also scsh has the right swiss-army-knife feel for this job, and the only problem is that it appears to be in a somewhat transitional state right now).

Best wishes,

Norman


-- 
Norman Gray  :  http://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK