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
I thought it might be a good idea to document how the above bug affects this module (and dependent modules like prompt). Calling read() with a WriteStream other than process.stdout as the output option (see #5) winds up causing end() to be called on the WriteStream instance. If you’re just doing a single prompt for user input this is no big deal, but subsequent prompts to the same WriteStream instance will not be shown to the user. The following code will reproduce the issue:
The 1st: prompt will be printed, but the 2nd: prompt will not be, because ttyWS got ended. Presumably this does not affect the default of process.stdout because of some io.js magic that re-opens process.stdout if there is an attempt to write to it when it has already been ended.
One workaround for users of the read module is to no-op the WriteStream instance’s end method, like so:
ttyWS.end=function(){}
Ultimately, the culprit here is this bug in mute-stream: npm/mute-stream#5, which lets the end() call pipe to the WriteStream instance. Fixing that and updating the dependency should fix this bug.
Thanks for taking a look at this!
The text was updated successfully, but these errors were encountered:
TL;DR: The mute-stream module needs a quick fix: npm/mute-stream#5
I thought it might be a good idea to document how the above bug affects this module (and dependent modules like prompt). Calling
read()
with a WriteStream other thanprocess.stdout
as theoutput
option (see #5) winds up causingend()
to be called on the WriteStream instance. If you’re just doing a single prompt for user input this is no big deal, but subsequent prompts to the same WriteStream instance will not be shown to the user. The following code will reproduce the issue:The
1st:
prompt will be printed, but the2nd:
prompt will not be, becausettyWS
gotend
ed. Presumably this does not affect the default ofprocess.stdout
because of some io.js magic that re-opensprocess.stdout
if there is an attempt to write to it when it has already beenend
ed.One workaround for users of the read module is to no-op the WriteStream instance’s
end
method, like so:Ultimately, the culprit here is this bug in mute-stream: npm/mute-stream#5, which lets the
end()
call pipe to the WriteStream instance. Fixing that and updating the dependency should fix this bug.Thanks for taking a look at this!
The text was updated successfully, but these errors were encountered: