child_process: async spawn methods not closing stdin

[silverwind]

Currently, there is no way to distinguish if the process is being piped/redirected to or if it is spawned by child_process.exec. The following examples both yield the exact same process.stdin object, leaving a script undecided whether it should wait for input on stdin if it choses to accept data on stdin:

Attached stdin

echo "something" | iojs -p process.stdin

Spawned by exec

iojs -p "require('child_process').exec('iojs -p process.stdin', function(err,stdout) { process.stdout.write(stdout); })"

If it is possible to distinguish these cases, I'd like to see a new property on process.stdin that returns true when the process has its stdin attached, false if it is not.

related: raineorshine/npm-check-updates#119
cc: @metaraine

[Fishrock123]

cc @bnoordhuis / @piscisaureus?

[bnoordhuis]

Currently, there is no way to distinguish if the process is being piped/redirected to or if it is spawned by child_process.exec.

There is no distinguishing between the two just by looking at stdin, it's a pipe in both cases. You could pass a value in the environment as an out-of-band signal but that requires cooperation between the parent and the child.

[silverwind]

it's a pipe in both cases

At which point is the pipe introduced in exec? From what I gather, it's basically /bin/sh -c command, which seems to be a regular fd to me when I try this:

$ /bin/sh -c "bash -c 'readlink /proc/$$/fd/1'"
/dev/pts/0

[silverwind]

Or maybe a better demonstration of what I mean:

$ /bin/sh -c "bash -c 'readlink -f /dev/stdin'"
/dev/pts/0

$ /bin/sh -c "echo 'a' | bash -c 'readlink -f /dev/stdin'"
/proc/2046/fd/pipe:[3219332]

The first case's (which I think is what exec does) stdin doesn't look like a pipe to me.

[bnoordhuis]

I think you subconsciously associate 'pipe' with the pipe character? I mean it in the system call sense, i.e. man 2 pipe.

[silverwind]

Indeed I was, I'll read that up, thanks.

[Trott]

@silverwind Is this still something you'd like to keep open?

[silverwind]

I think I found a somewhat workable solution by resolving the stdin symlink. I still don't understand why it logs socket:[26350] in the child_process case though, as @bnoordhuis mentioned it should be a pipe.

"use strict";
var fs = require("fs");

function resolveLink(link, cb) {
  fs.lstat(link, function (err, stat) {
    if (err) return cb(link);
    if (stat.isSymbolicLink()) {
      fs.readlink(link, function (err, linkString) {
        resolveLink(linkString, cb);
      })
    } else {
      cb(link);
    }
  });
};

resolveLink("/dev/stdin", console.log);

$ node log-stdin.js
/dev/pts/1
$ echo "a" | node log-stdin.js
pipe:[28908]
$ node -p 'require("child_process").execSync("node log-stdin.js").toString().trim()'
socket:[26350]

[bnoordhuis]

@silverwind execSync() creates a UNIX socketpair; it's mostly interchangeable with a pipe except it can also be used to send over file descriptors.

[Fishrock123]

@silverwind is this still viable, or should we close it?

@silverwind
all three of those branches print out "fd/0" from the symbolic link branch on osx node 7.4.0

so there's no way to tell (without incorporating an additional flag/option to the child script) if a process is spawned vs being piped input to?