Sitelet https://github.com/nodejs/node/issues/8839
Skip to content

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

Closed
Closed
process.stdin is not implemented in bash for Windows 10... unknown type#8839
Labels
child_processIssues and PRs related to the child_process subsystem.libuvIssues and PRs related to the libuv dependency or the uv binding.processIssues and PRs related to the process subsystem.windowsIssues and PRs related to the Windows platform.wslIssues and PRs related to the Windows Subsystem for Linux.

Description

@catdad
catdad
opened on Sep 28, 2016
  • 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.

Activity

  1. addaleax
    added
    child_processIssues and PRs related to the child_process subsystem.
    windowsIssues and PRs related to the Windows platform.
    processIssues and PRs related to the process subsystem.
    on Sep 28, 2016
  2. Fishrock123
    added
    libuvIssues and PRs related to the libuv dependency or the uv binding.
    on Sep 29, 2016

  3. Fishrock123 commented on Sep 29, 2016

    @Fishrock123
    Fishrock123
    on Sep 29, 2016
    Contributor

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

  4. Fishrock123
    added
    child_processIssues and PRs related to the child_process subsystem.
    and removed
    child_processIssues and PRs related to the child_process subsystem.
    on Sep 29, 2016

  5. bnoordhuis commented on Sep 29, 2016

    @bnoordhuis
    bnoordhuis
    on Sep 29, 2016
    Member

    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.

  6. saghul commented on Sep 29, 2016

    @saghul
    saghul
    on Sep 29, 2016
    Member

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

  7. saghul commented on Sep 30, 2016

    @saghul
    saghul
    on Sep 30, 2016
    Member

    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.

  8. bnoordhuis commented on Oct 1, 2016

    @bnoordhuis
    bnoordhuis
    on Oct 1, 2016
    Member

    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.

  9. bnoordhuis
    closed this as completedon Oct 1, 2016
  10. refack
    added
    wslIssues and PRs related to the Windows Subsystem for Linux.
    on Jul 22, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    child_processIssues and PRs related to the child_process subsystem.libuvIssues and PRs related to the libuv dependency or the uv binding.processIssues and PRs related to the process subsystem.windowsIssues and PRs related to the Windows platform.wslIssues and PRs related to the Windows Subsystem for Linux.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions