FIFO File Descriptors Created in process substitution aren't handled consistently

[cfogrady]

At the moment an OpenHandler can be provided to an interp.Runner as a RunnerOption.

When a process substitution creates a FIFO path it is created on the os filesystem; however, later operations sent to it treat it as a normal file sent to the OpenHandler. This has a side effect that if the OpenHandler is mocked or is sandboxed in some way, that the open file for the process substitution's named pipe hangs because writes are going to the wrong file.

I would propose one of the following:

1. Changing documentation such that users are specifically warned against sandboxing OpenHandler because of such scenarios
2. Changing the https://github.com/mvdan/sh/blob/master/interp/runner.go#L107 and https://github.com/mvdan/sh/blob/master/interp/runner.go#L120 to use the OpenHandler instead of directly interacting with the OS, which may also involve a handler for removing the file
3. Provide a way to internally differentiate between Named Pipes and regular files before the OpenHandler is called.

[mvdan]

Thanks for filing this; I think this was simply an oversight. I'll need to think about this because, as you point out, there's no clear and easy solution here.

Named pipes themselves are also created directly and not via any handler, so that's also part of the problem. At least that one is excusable, given that one can't create a named pipe via os.OpenFile.

Given that named pipes are somewhat special (they need to be created in a special way, and they need to be removed later) perhaps they do need to be split apart from the open handler entirely. The named pipes are created by the interpreter internals anyway, and get placed in temporary directories so that they're out of the way - so I also don't think that anyone writing a "file handler sandbox" should care about them.

Hence I currently lean towards a form of option 3, perhaps even so that OpenHandler is not called at all for named pipes created by the interpreter.