-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accessing stdin with file descriptor 0 on Windows causes exception if there's no input / if stdin is closed #19831
Comments
Can reproduce this on Win. |
Just confirmed, works on both Linux and MacOS. @mklement0 @jens1o could you try a few other versions of Node? Does this also happen on LTS? |
Window 7 x64. |
@vsemozhetbyt if it's okay with nightly, can't we just find out which commit "accidentally" fixed it and backport it? |
I can try to brute-force-bisect) |
Unbreak point: > node.v10.0.0-nightly20180116f75bc2c1a5.exe -pe "require('fs').readFileSync(0).toString()"
fs.js:634
binding.fstat(fd);
^
Error: EBADF: bad file descriptor, fstat
at tryStatSync (fs.js:634:13)
at Object.fs.readFileSync (fs.js:670:3)
at [eval]:1:15
at Script.runInThisContext (vm.js:64:33)
at Object.runInThisContext (vm.js:185:38)
at Object.<anonymous> ([eval]-wrapper:6:22)
at Module._compile (module.js:660:30)
at evalScript (bootstrap_node.js:484:27)
at startup (bootstrap_node.js:170:9)
at bootstrap_node.js:640:3
> node.v10.0.0-nightly20180116f75bc2c1a5.exe -pe "require('fs').readFileSync(0).toString()" < NUL
fs.js:634
binding.fstat(fd);
^
Error: EINVAL: invalid argument, fstat
at tryStatSync (fs.js:634:13)
at Object.fs.readFileSync (fs.js:670:3)
at [eval]:1:15
at Script.runInThisContext (vm.js:64:33)
at Object.runInThisContext (vm.js:185:38)
at Object.<anonymous> ([eval]-wrapper:6:22)
at Module._compile (module.js:660:30)
at evalScript (bootstrap_node.js:484:27)
at startup (bootstrap_node.js:170:9)
at bootstrap_node.js:640:3
> node.v10.0.0-nightly201801171b0d9795b6.exe -pe "require('fs').readFileSync(0).toString()"
123
^Z
123
> node.v10.0.0-nightly201801171b0d9795b6.exe -pe "require('fs').readFileSync(0).toString()" < NUL
> |
So it seems some of these commits may have the fix: |
@vsemozhetbyt perhaps 8c00a80? |
Let's see what @nodejs/fs think) |
This was fixed in 8c00a80 but then it was broken again in #20167. Now we get: >node -pe "require('fs').readFileSync(0).toString()"
fs.js:163
return (stats[1/* mode */] & S_IFMT) === fileType;
^
TypeError: Cannot read property '1' of undefined
at isFileType (fs.js:163:16)
at Object.fs.readFileSync (fs.js:455:7)
at [eval]:1:15
at Script.runInThisContext (vm.js:91:20)
at Object.runInThisContext (vm.js:298:38)
at Object.<anonymous> ([eval]-wrapper:6:22)
at Module._compile (internal/modules/cjs/loader.js:678:30)
at evalScript (internal/bootstrap/node.js:542:27)
at startup (internal/bootstrap/node.js:204:9)
at bootstrapNodeJSCore (internal/bootstrap/node.js:575:3) /cc @joyeecheung EDIT: it only reproduces on Windows, on Linux it works fine |
@bzoz Thanks for the ping. Looks like it's a corner case of
|
Also this is where the root cause is:
|
@joyeecheung is this fixed? Can this be closed? |
This might be related to #20640 (which currently can’t really move forward without some macOS help)? |
@addaleax I'll try to help out. |
Still an issue with latest nodejs on windows. Unable to read stdin :/. Works fine on linux and windows using git bash, but powershell fails (e.g. cat somefile | myscript). |
@GiGurra Is |
@addaleax I have been looking into this now for a couple of hours and have found what I believe could be the source of my issue.
My test script is as simple as it gets :)
npm link/install on the above and then doing I believe it has to do with how powershell works together with the startup script that npm install creates. ( I dont know much/anything about powershell tbh, but it seems like it does some funky stuff to stdin -not just forwarding it to any child processes spawned by the powershell script, and in the process the generated powershell script for any cli application installed with npm install will lose access to stdin. Conclusion: The powershell startup script that npm install/link creates does not forward stdin properly/at all. Update: Confirmed. If explicitly tell powershell to use the generated cmd script, it works fine :)
|
Note that the commands in the OP still fail, irrespective of whether you run them from However, the error message for closed stdin / empty input has changed and is now:
@GiGurra: I suspect the PowerShell issue you're describing is a separate issue: it may be that the I'm not familiar with the mechanism that auto-generates Here's an example that shows that nonempty stdin input is received in a PowerShell Script: Create test file $Input | node -pe "require('fs').readFileSync(0).toString()" Then invoke it from PowerShell as follows, and you'll see that the stdin input is correctly received and echoed: # Provide stdin input and echo it.
PS> 'echo me' | .\t.ps1
echo me Again, not providing stdin input surfaces the error, albeit with a different error message - whether that points to yet another problem is unclear to me: # Provide NO stdin input
PS> .\t.ps1
internal/fs/utils.js:220
throw err;
^
Error: EOF: end of file, read
... |
Do things work if you use |
The following work correctly:
Without the |
It’s intentional that I’m actually personally a bit torn on whether this is the right behaviour, i.e. whether |
This looks a bit like a programing error to me. On Windows you can't just write to fd 0 on all shells. You may need to do it to |
@saghul: Given that we're talking about standard input, you probably meant
The standard streams are not shell features, they're system features. Shells may choose to surface them differently, though, as PowerShell does via Whatever the calling shell, |
I've investigated this issue with Node v18.20.2, v20.16.0 and v22.7.0. Both v20 and v22 worked as expected. I guess v18 doesn't have the latest libuv release because it still has this issue. |
Thanks, @huseyinacacak-janea. Indeed, the problem seems to be fixed in the LTS version that is current as of this writing (v20.x), so I'm closing this. |
v9.11.1
Windows 10 Pro (64-bit; v10.0.15063)
fs
moduleOn Windows, run the following from a
cmd.exe
console ("Command Prompt"):The last 2 commands break as follows:
Using
.readFile()
and thereadline
module is equally affected.On Unix platforms, the behavior is as expected in all cases.
The text was updated successfully, but these errors were encountered: