Skip to content

Conversation

@mostafaroshdy1
Copy link

@mostafaroshdy1 mostafaroshdy1 commented Nov 9, 2025

Update the CommonJS module loader to detect when the input filename is /dev/stdin and stdin is a pipe. In such cases, read directly from file descriptor 0 instead of attempting to open the /proc//fd/pipe:[...] path, which can result in ENOENT errors.

This change ensures that running Node with piped input like:
printf 'console.log(1)' | node /dev/stdin
works reliably on Linux systems.

Fixes: #54200

Update the CommonJS module loader to detect when the input
filename is /dev/stdin and stdin is a pipe (FIFO). In such
cases, read directly from file descriptor 0 instead of
attempting to open the /proc/<pid>/fd/pipe:[...] path, which
can result in ENOENT errors.

This change ensures that running Node with piped input like:
  printf 'console.log(1)' | node /dev/stdin
works reliably on Linux systems.

Fixes: nodejs#54200
@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/loaders

@nodejs-github-bot nodejs-github-bot added module Issues and PRs related to the module subsystem. needs-ci PRs that need a full CI run. labels Nov 9, 2025
@aduh95
Copy link
Contributor

aduh95 commented Nov 10, 2025

Why not use - – or simply nothing

$ printf 'console.log(1)' | node -
1
$ printf 'console.log(1)' | node
1

@mostafaroshdy1
Copy link
Author

Why not use - – or simply nothing

$ printf 'console.log(1)' | node -
1
$ printf 'console.log(1)' | node
1

Your snippet works correctly on Linux, but the issue specifically affects the case where node /dev/stdin is used.

On macOS, printf 'console.log(1)' | node /dev/stdin works as expected, but on Linux it fails because /dev/stdin resolves to a /proc/<pid>/fd/pipe:[xxxx] path that cannot be opened directly.

The fix ensures consistent behavior across platforms for this pattern.

@Renegade334
Copy link
Member

This sort of thing has been reported before (#60342) but I wouldn't say that a hardcoded check for one specific path lends "consistency", and it's probably the one with the least motivation to address, given that – as mentioned – there's no need to provide a path to stdin to the CLI at all.

As far as the loader handling quirky symlinks to anonymous pipes goes, you can pass --preserve-symlinks if you really need to use these. The error message is a little confusing in these cases, and maybe there's a case for reporting a specific error, or adding to the existing error, in cases where a symlink has been followed but the resulting target fails to open.

@mostafaroshdy1
Copy link
Author

@Renegade334 Thanks for providing more context.
What I meant by “consistency” was referring to the behavior itself, not necessarily the specific solution.
I’m completely open to discussing alternative approaches if needed , otherwise, this PR and the related issue can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

module Issues and PRs related to the module subsystem. needs-ci PRs that need a full CI run.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

can't execute /dev/stdin on linux

5 participants