`process.stdin` is not implemented in bash for Windows 10... unknown type

[catdad]

• Version: 6.4.0 and 4.5.0 tested
• Platform: bash on Windows 10 64bit
• Subsystem: stdio (I think?)

uname output, just in case: Linux WHITSON 3.4.0+ #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 x86_64 x86_64 x86_64

Repro code:

var exec = require('child_process').exec;
var fs = require('fs');

var stream = fs.createReadStream('./repro.js');

var child = exec(
    'node -e "process.stdin.pipe(process.stdout)"',
    { cwd: process.cwd() },
    console.log.bind(console, 'result args:')
);

stream.pipe(child.stdin);

I named this file repro.js... yes, it reads itself, but any stream will reproduce this error.

Then run: node repro.js

This will output:

kiril@WHITSON:~/temp$ node repro.js
result args: { [Error: Command failed: /bin/sh -c node -e "process.stdin.pipe(process.stdout)"
node.js:708
          throw new Error('Implement me. Unknown stdin file type!');
          ^

Error: Implement me. Unknown stdin file type!
    at process.stdin (node.js:708:17)
    at [eval]:1:8
    at Object.exports.runInThisContext (vm.js:54:17)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (module.js:409:26)
    at node.js:579:27
    at nextTickCallbackWith0Args (node.js:420:9)
    at process._tickCallback (node.js:349:13)
]
  killed: false,
  code: 1,
  signal: null,
  cmd: '/bin/sh -c node -e "process.stdin.pipe(process.stdout)"' }  node.js:708
          throw new Error('Implement me. Unknown stdin file type!');
          ^

Error: Implement me. Unknown stdin file type!
    at process.stdin (node.js:708:17)
    at [eval]:1:8
    at Object.exports.runInThisContext (vm.js:54:17)
    at Object.<anonymous> ([eval]-wrapper:6:22)
    at Module._compile (module.js:409:26)
    at node.js:579:27
    at nextTickCallbackWith0Args (node.js:420:9)
    at process._tickCallback (node.js:349:13)

This code works correctly (outputting the contents of the file itself) on regular Ubuntu and regular Windows, but not on the Linux subsystem in Windows 10.

This was discovered in catdad/shellton#11.

Same issue happens with spawn as well, obviously, but it's tougher to get the error.

[Fishrock123]

cc @saghul / @bnoordhuis any idea why this would happen? This is coming from Libuv's file descriptor detection.

[bnoordhuis]

It's almost certainly a bug in MS's emulation layer. Libuv detects the file type by checking the output of fstat() and getsockname/getsockopt(); Windows probably doesn't implement those with enough fidelity to pass the sniff test.

[saghul]

I'll try to give it a shot during the weekend, but what Ben says sounds about right, fstat is probably lying.

[saghul]

I could reproduce this. The problem is indeed that tty_wrap.guessHandleType returns 'UNKNOWN'. I modified the test case a bit to log .fs.fstatSync(0) and this is what we get:

{ dev: 0,
  mode: 49663,
  nlink: 1,
  uid: 0,
  gid: 0,
  rdev: 0,
  blksize: 512,
  ino: 961,
  size: 0,
  blocks: 0,
  atime: 1970-01-01T00:00:00.000Z,
  mtime: 1970-01-01T00:00:00.000Z,
  ctime: 1970-01-01T00:00:00.000Z,
  birthtime: 1970-01-01T00:00:00.000Z }

So, looks like the pipe(2) we internally create to communicate with the child process is not detected as such inside the child itself when doing fstat.

Not sure what we can do here, it's certainly a WSL bug AFAIS.

[bnoordhuis]

The mode field looks okay; it's 140777 in octal, indicating it's a socket (same value it has on real Linux) so that probably means getsockopt(SOL_SOCKET, SO_TYPE) doesn't work. I'm going to guess that it hasn't been implemented or not implemented correctly for UNIX socketpairs, which is what node.js uses to communicate with child processes.

Aside, the fact that the dev field is zero is a little suspect and will probably trip up some programs. I'm going to close the issue; @catdad you should take this up with MS.

cc @joshgav, just in case.