Add {value: 'pipe', input: true} to use an additional file descriptor as input#1246
Conversation
…or as input
For file descriptors beyond `stdin`/`stdout`/`stderr`, `'pipe'` is ambiguous: Execa cannot tell whether it is meant for input or output, so it defaults to output. This made it impossible to write into an extra file descriptor, e.g. `.duplex({to: 'fd3'})`, without the buggy `['pipe', []]` workaround.
The new `{value: 'pipe', input: true}` object form explicitly marks such a file descriptor as input.
Fixes #1214
sindresorhus
force-pushed
the
fd-input-pipe
branch
from
a13248a to
c75e22e
Compare
| A single string can be used [as a shortcut](output.md#shortcut). | ||
|
|
||
| The array can have more than 3 items, to create [additional file descriptors](output.md#additional-file-descriptors) beyond [`stdin`](#optionsstdin)/[`stdout`](#optionsstdout)/[`stderr`](#optionsstderr). | ||
| The array can have more than 3 items, to create [additional file descriptors](output.md#additional-file-descriptors) beyond [`stdin`](#optionsstdin)/[`stdout`](#optionsstdout)/[`stderr`](#optionsstderr). Passing `'pipe'` to an additional file descriptor defaults it to output. To use it for [input](input.md#additional-file-descriptors) instead, pass `{value: 'pipe', input: true}`. |
There was a problem hiding this comment.
Can only 'pipe' be ambiguous? For example, I would imagine 'inherit' could be possibly used for both input and output in fd3? Same with streams that are both readable and writable, or with files.
There was a problem hiding this comment.
I considered that, but I scoped it to 'pipe'/'overlapped' because that's what #1214 was about (the buggy ['pipe', []] workaround), but 'inherit' and files indeed share the same limitation. I'll look into it.
There was a problem hiding this comment.
I was only mentioning 'pipe' in the issue because that was the specific instance the user was experiencing, but the problem was more generic, in that it impacts other values.
I am actually wondering whether allowing any value would simplify the implementation, since some of the logic right now is making sure 'pipe' is used. Technically, some values do not make sense as input, namely 1, 2 or any non-readable stream (Node.js or web). But using fd3 + {input: true} + one of those values seems like such an edge case, which is going to fail runtime anyway, that it might not deserve any safeguard.
2 participants
For file dscriptors beyond
stdin/stdout/stderr,'pipe'is ambiguous: Execa cannot tell whether it is meant for input or output, so it defaults to output. This made it impossible to write into an extra file descriptor, e.g..duplex({to: 'fd3'}), without the buggy['pipe', []]workaround.The new
{value: 'pipe', input: true}object form explicitly marks such a file descriptor as input.Fixes #1214