You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a problem with Bash having problems with output piping. If I specify { stdio: 'inhert' }, it works but that way I then have no way of getting that data. { stdio: 'pipe' } produces the error above
Sorry for the late comment on this one. Main reason for the delay is that I did not want to comment until I have tried it myself and I did not have node.exe on my system.
I still get an error here on the latest build, but it at least is a different error (no more helpful).
We will look into this one, but I can not promise anything.
This is actually very crucial to many applications of WSL. For example in my case I have to make Atom-Hack (HackLang plugin for Atom Editor) work by executing a Hack Linter inside the WSL and pipe its output to Atom's linter. There are a lot of use cases for this.
You can actually try this on Python too as suggested here
We have a known limitation where we only support the console for stdin and stdout. If either of those are not a console then we will fail. That said, I believe I'm telling you things you already know with your last comment in #20.
We do understand that this is a limitation and does block some scenarios. It is on the backlog. My suggestion at this point would be to add it to our User Voice page and go for the up votes to help raise the priority.
g++ a.cpp -o a then compile and run main.cpp in windows. the out.txt file appear with the right content.
so here is a temporary solution:
1.use a wraper to write everything into a file
2.read that file in windows
2016/04/15 update:
It turn out system works just fine in C++(at least in Dev-C++/TDM-GCC),both bash -c "ls >out.txt" and bash -c "ls" works fine. However, when node.js called it, above problem appeared.
Thanks for creating the UserVoice page. I wanted to be clear that this is definitely very high on our internal list of things we want to implement for future updates.
I just tried with fresh W10 14965.1001 from ISO, but I am having some problems still (though the line in my previous post does not throw any error).
The problem occurs in write method plus the traces from output pipes do not appear:
this.sendEvent(newOutputEvent(`STARTING\n`,'stderr'));try{varprocess=spawn("bash",["-c",`echo WHATEVER >&3`],{stdio: ["pipe","pipe","pipe","pipe"]});process.stdin.write(`DATA DATA DATA \n`);process.stdio[3].on("data",(data)=>{this.sendEvent(newOutputEvent(`${data}`,'stderr'));});}catch(ex){this.sendEvent(newOutputEvent(`EXCEPTION ${ex}\n ${ex.stack}\n`,'stderr'));}this.sendEvent(newOutputEvent(`STARTED\n`,'stderr'));
Output shows Error: write EPIPE in Socket._writeGeneric():
STARTING
EXCEPTION Error: write EPIPE
Error: write EPIPE
at exports._errnoException (util.js:1026:11)
at Socket._writeGeneric (net.js:706:26)
at Socket._write (net.js:725:8)
at doWrite (_stream_writable.js:307:12)
at writeOrBuffer (_stream_writable.js:293:5)
at Socket.Writable.write (_stream_writable.js:220:11)
at Socket.write (net.js:651:40)
at BashDebugSession.launchRequest (bashDebug.js)
...
STARTED
What is stdio[3] supposed to be? Maybe that's the issue, that there is only stdin/stdout/stderr? Anyway, Imo this is getting offtopic for this thread and pretty node-specific, you may want to open a new issue to not spam everyone. You also don't handle your errors correctly, those functions will never throw synchronously, you need to attach an error event handler.
Felix Becker (@felixfbecker) Well, stdio[3] is just another (non-standard) pipe passed to child process. It works fine when using cmd.exe instead of bash.exe.
Anyway, this is off-topic, so I will end here (and check the error correctly).
...Thanks to proper error handling, the error turned out to be in spawn ("ENOENT"), which I was able to fix by providing full bash path ("C:\Windows\sysnative\bash.exe"). Thank you for help...
Hi Alan Zanatta (@alanzanattadev) -- WSL changes (excluding serious security flaws and similar) are batched and merged to stable Windows 10 only as part of major Windows releases. The next major Windows release is the "Creators" update. Note that this will be the first update after WSL's initial public release, so basically everything active or pending in this ticket-tracker is targeted at it :-)
Microsoft has not stated a release date yet for Creators, but the latest Internet rumors have it coming out in a month or so.
Adam Seering (@aseering) Ok :) thank you for your quick answer, do you recommand going into Insider ? Can I rollback to stable version somehow if I switch ? I need this feature :(
So, I have two Windows computers. (First-order approximation :-) ) My main one runs the latest Insider build. Most of the time I'm very happy with it. Every now and then (a few times per year?) there's a bad build, in which case I usually just use my other computer for a while. It's been quite stable recently; they have been keeping things atable in preparation for the upcoming release. (I expect it will be a smooth upgrade from Insider builds to the Creators release when it ships.)
You can generally revert to previous Insider builds (though I usually don't bother) as long as you have a system restore point. You can try to roll all the way back to the latest stable release but they're so different at this point that the revert might not go smoothly? I only tried that once, months ago, but it worked ok.
I guess I haven't answered your question :-) In short -- in exchange for features, how much risk are you comfortable dealing with?
Activity
patryk9200 commentedon Apr 7, 2016
Try by changing encoding. I don't have problem to run bash -c "ls" from CMD.
Try UTF16 or Latin II (852). I have in CMD Latin II encodig by default.
RaeesBhatti commentedon Apr 7, 2016
NodesJS says unknown encoding for both UTF-16 and ISO-8859-2. And it works just find in the CMD. Just not in NodeJS
RaeesBhatti commentedon Apr 7, 2016
This is a problem with Bash having problems with output piping. If I specify
{ stdio: 'inhert' }, it works but that way I then have no way of getting that data.{ stdio: 'pipe' }produces the error above[-]Unable to spawn Bash from other programs[/-][+]Unable to pipe Bash output to other programs[/+]RaeesBhatti commentedon Apr 7, 2016
Ref: MicrosoftDocs/WSL#8 (comment)
RaeesBhatti commentedon Apr 7, 2016
/cc Russ Alexander (@russalex)
tkelman commentedon Apr 11, 2016
Same from mintty (the terminal emulator used by cygwin and msys2), which uses named pipes for stdin/stdout:
russalex commentedon Apr 12, 2016
Sorry for the late comment on this one. Main reason for the delay is that I did not want to comment until I have tried it myself and I did not have node.exe on my system.
I still get an error here on the latest build, but it at least is a different error (no more helpful).
We will look into this one, but I can not promise anything.
RaeesBhatti commentedon Apr 12, 2016
This is actually very crucial to many applications of WSL. For example in my case I have to make Atom-Hack (HackLang plugin for Atom Editor) work by executing a Hack Linter inside the WSL and pipe its output to Atom's linter. There are a lot of use cases for this.
You can actually try this on Python too as suggested here
russalex commentedon Apr 12, 2016
We have a known limitation where we only support the console for stdin and stdout. If either of those are not a console then we will fail. That said, I believe I'm telling you things you already know with your last comment in #20.
We do understand that this is a limitation and does block some scenarios. It is on the backlog. My suggestion at this point would be to add it to our User Voice page and go for the up votes to help raise the priority.
wywzxxz commentedon Apr 14, 2016
node.js spawn have the same problem.
and
popenin C++ have the problem(tested with Dev-c++).however,If there is no output,then It works fine.
here is an example:
a.cpp
main.cpp
g++ a.cpp -o a then compile and run main.cpp in windows. the out.txt file appear with the right content.
so here is a temporary solution:
1.use a wraper to write everything into a file
2.read that file in windows
2016/04/15 update:
It turn out system works just fine in C++(at least in Dev-C++/TDM-GCC),both
bash -c "ls >out.txt"andbash -c "ls"works fine. However, when node.js called it, above problem appeared.RaeesBhatti commentedon Apr 14, 2016
I've just purposed a UserVoice Idea for this problem. Anyone who wants to see this fixed, can vote for it.
benhillis commentedon Apr 14, 2016
Thanks for creating the UserVoice page. I wanted to be clear that this is definitely very high on our internal list of things we want to implement for future updates.
mjoppich commentedon Apr 26, 2016
Is there any quick fix around the corner ... i'd desperately love to grab the output from bash -c :S
As a first "quick fix" is it somehow possible to save the output from bash to file?
18 remaining items
rogalmic commentedon Dec 11, 2016
Felix Becker (@felixfbecker)
I just tried with fresh W10 14965.1001 from ISO, but I am having some problems still (though the line in my previous post does not throw any error).
The problem occurs in write method plus the traces from output pipes do not appear:
Output shows Error: write EPIPE in Socket._writeGeneric():
Am I doing something wrong?
felixfbecker commentedon Dec 11, 2016
What is
stdio[3]supposed to be? Maybe that's the issue, that there is only stdin/stdout/stderr? Anyway, Imo this is getting offtopic for this thread and pretty node-specific, you may want to open a new issue to not spam everyone. You also don't handle your errors correctly, those functions will never throw synchronously, you need to attach anerrorevent handler.rogalmic commentedon Dec 11, 2016
Felix Becker (@felixfbecker) Well, stdio[3] is just another (non-standard) pipe passed to child process. It works fine when using cmd.exe instead of bash.exe.
Anyway, this is off-topic, so I will end here (and check the error correctly).
...Thanks to proper error handling, the error turned out to be in spawn ("ENOENT"), which I was able to fix by providing full bash path ("C:\Windows\sysnative\bash.exe"). Thank you for help...
chidea commentedon Jan 24, 2017
I've wrote a program to solve this by managing temporary pipe/argument files.
http://github.com/chidea/GttBoW
alanzanattadev commentedon Mar 22, 2017
Any news for official windows 10 support (not insider) of bash running under node on windows 10 ?
aseering commentedon Mar 22, 2017
Hi Alan Zanatta (@alanzanattadev) -- WSL changes (excluding serious security flaws and similar) are batched and merged to stable Windows 10 only as part of major Windows releases. The next major Windows release is the "Creators" update. Note that this will be the first update after WSL's initial public release, so basically everything active or pending in this ticket-tracker is targeted at it :-)
Microsoft has not stated a release date yet for Creators, but the latest Internet rumors have it coming out in a month or so.
alanzanattadev commentedon Mar 22, 2017
Adam Seering (@aseering) Ok :) thank you for your quick answer, do you recommand going into Insider ? Can I rollback to stable version somehow if I switch ? I need this feature :(
aseering commentedon Mar 22, 2017
So, I have two Windows computers. (First-order approximation :-) ) My main one runs the latest Insider build. Most of the time I'm very happy with it. Every now and then (a few times per year?) there's a bad build, in which case I usually just use my other computer for a while. It's been quite stable recently; they have been keeping things atable in preparation for the upcoming release. (I expect it will be a smooth upgrade from Insider builds to the Creators release when it ships.)
You can generally revert to previous Insider builds (though I usually don't bother) as long as you have a system restore point. You can try to roll all the way back to the latest stable release but they're so different at this point that the revert might not go smoothly? I only tried that once, months ago, but it worked ok.
I guess I haven't answered your question :-) In short -- in exchange for features, how much risk are you comfortable dealing with?
alanzanattadev commentedon Mar 22, 2017
I need to have a stable platform for development :( I guess I have to wait, thank you for all !
benhillis commentedon Mar 22, 2017
Alan Zanatta (@alanzanattadev) - As Adam Seering (@aseering) mentioned you won't have to wait long. Creators update is coming soon.
benhillis commentedon Jul 14, 2017
Sorry I was just trying to clean up misleading information.
Copilot feedback #2 and format