Support of linux files pointed by /dev/fd/XX as the scripts

[vinci-mz]

• v8.9.4:
• Linux 3.2.0-4-686-pae # 1 SMP Debian 3.2.73-2+deb7u2 i686 GNU/Linux

Hello,
it seems files pointed by /dev/fd/XX are not supported by node as scrips:

$ cat <( echo 'console.log(123);' )
console.log(123);

$ node <( echo 'console.log(123);' )
fs.js:646
  return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
                 ^

Error: ENOENT: no such file or directory, open '/proc/29648/fd/pipe:[14154170]'
    at Object.fs.openSync (fs.js:646:18)
    at Object.fs.readFileSync (fs.js:551:33)
    at Object.Module._extensions..js (module.js:653:20)
    at Module.load (module.js:556:32)
    at tryModuleLoad (module.js:499:12)
    at Function.Module._load (module.js:491:3)
    at Function.Module.runMain (module.js:684:10)
    at startup (bootstrap_node.js:187:16)
    at bootstrap_node.js:608:3

It is strange because fs.readFileSync (mentioned by node above) seems to be able to read such files:

$ cat test.js 
var fs=require('fs');
console.log('Reading', process.argv[2]);
fs.readFileSync(process.argv[2]);

$ node test.js  <( echo 'console.log(123);' )
Reading /dev/fd/63

(/dev/fd/63 is a link to a file /proc/29648/fd/pipe...)
This issue may be related to the old one: nodejs/node-v0.x-archive#7101

[bnoordhuis]

That's because the module loader canonicalizes paths by resolving all symlinks. /dev/fd/<n> is a symlink to /proc/self/fd/<n>, which is itself a symlink to pipe:[xxx] even though that's not an existing path, and that's why you see the behavior that you see.

I wouldn't qualify this as a bug in node.js.

[vinci-mz]

Let me notice that the all mentioned paths are links to the existing (temporary) file, and the last example (script test.js) successfully reads the contents of such file...

[bnoordhuis]

You misunderstand. Try this in your script:

fs.readFileSync(fs.realpathSync(process.argv[2]));  // fails with ENOENT

[vinci-mz]

Well, I see the ENOENT in your example as well as in the original (initially posted) message of node . But this message seems to be not appropriate / misleading, look at the following:

$ cat test.js 
var fs=require('fs');
console.log('Reading', process.argv[2]);
console.log(String(fs.readFileSync(process.argv[2])));

$ node test.js  <( echo 'console.log(123);' )
Reading /dev/fd/63
console.log(123)

Believe me ;-) both those links (/dev/fd/<n>, /proc/<pid>/fd/<n>) points an existing (though maybe not completely regular) file /proc/<pid>/fd/pipe:[xxx]...

[bnoordhuis]

Node.js is hardly unique in this:

$ python -c 'import os,sys; open(os.path.realpath(sys.argv[1]))' <(true)
Traceback (most recent call last):
  File "<string>", line 1, in <module>
IOError: [Errno 2] No such file or directory: '/proc/2277/fd/pipe:[35230]'

It's a procfs quirk and since I don't think we'll be encumbering the module loader with fragile file system-specific error detection, I'll go ahead and close this out. Thanks anyway for the bug report.

[vinci-mz]

You are right - other dev tools seem to have similar troubles.
Thanks for your explanations and support.

[kenorb]

Try using this syntax instead:

node < <( echo 'console.log(123);' )

---

When you use:

node <( echo 'console.log(123);' )

it fails when a piped program closes the read pipe before the previous program is finished writing the whole output, that's why there is a 'no such file or directory' error. Some commands can handle closing a pipe in the middle of the code, some not.

[rektide]

I like the idea in #23267 (comment) :

Fwiw, this currently works when running node --preserve-symlinks-main… I’m wondering whether it might make sense to enable that as a fallback if the realpath’ed target file cannot be opened?

[thoughtsunificator]

First I want to say that yes I do agree with the initial observation of not being worth the trouble but...

Is this really about supporting "more" of the Linux platform, though?

One could say that Linux, or more generally, Unix systems have their own semantics of what files are, and Unix basically says that everything is a file.