Skip to content
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

fs: make process.stdout and stderr descend from Writable. #8828

Closed
mcollina opened this issue Sep 28, 2016 · 8 comments
Closed

fs: make process.stdout and stderr descend from Writable. #8828

mcollina opened this issue Sep 28, 2016 · 8 comments
Labels
confirmed-bug Issues with confirmed bugs. fs Issues and PRs related to the fs subsystem / file system. process Issues and PRs related to the process subsystem. stream Issues and PRs related to the stream subsystem.

Comments

@mcollina
Copy link
Member

process.stdout and process.stderr are not implementing Stream 2 or 3 if they are redirected to a file. They are a SyncWriteStream:

stream = new fs.SyncWriteStream(fd, { autoClose: false });
.
This is were the choice is made.:
case 'FILE':
const fs = require('internal/fs');
stream = new fs.SyncWriteStream(fd, { autoClose: false });
stream._type = 'fs';
break;

I know too little of the stdio sync/async situation to identify what should be preferred change. Ideally process.stdout and process.stderr should come from the streams implementations, but I might be wrong.
What are the implications of doing so? Why is this needed in the first place?
As an example, can we use net.Socket instead

stream = new net.Socket({
fd: fd,
readable: false,
writable: true
});
?

Issues related:
sindresorhus/is-stream#5
pinojs/pino#85
pinojs/pino#86

cc @jasnell @Fishrock123 @jsumners @catdad @sindresorhus @nodejs/streams

@mcollina mcollina added fs Issues and PRs related to the fs subsystem / file system. stream Issues and PRs related to the stream subsystem. confirmed-bug Issues with confirmed bugs. labels Sep 28, 2016
@addaleax
Copy link
Member

Ideally process.stdout and process.stderr should come from the streams implementations, but I might be wrong.

+1. It also looks like the SyncWriteStream implementation could be simplified a lot when built on top of Writable… I’ll try to put a patch together but it seems hard to estimate the semverness of that.

@jasnell
Copy link
Member

jasnell commented Sep 28, 2016

+1 on doing something here. As far as I understand it, the SyncWriteStream impl that was there had been intended as a kind of temporary half measure but it was never really finished. It's likely to be a semver-major change but hard to say for sure until we get a better implementation.

@Fishrock123
Copy link
Contributor

Hmmm, I was sure there was an older issue for this.

I think it would be ideal to change it to use net.Socket, there are a lot of subtle issues that come into play with properties not existing if someone pipes to/from a file. I doubt that would be a major change, it fixes the need for workarounds.

@Fishrock123 Fishrock123 added process Issues and PRs related to the process subsystem. fs Issues and PRs related to the fs subsystem / file system. and removed fs Issues and PRs related to the fs subsystem / file system. labels Sep 28, 2016
@mcollina
Copy link
Member Author

@Fishrock123 maybe there is, I found none mentioning SyncWriteStream directly.

@mcollina
Copy link
Member Author

SyncWriteStream is mainly used within the debug module https://github.com/visionmedia/debug/blob/39ecd87bcc145de5ca1cbea1bf4caed02c34d30a/node.js#L164. debug lifts some chunks of code straight from core.

addaleax added a commit to addaleax/node that referenced this issue Sep 28, 2016
Make the internal `SyncWriteStream` a proper `stream.Writable`
subclass. This allows for quite a bit of simplification, since
`SyncWriteStream` predates the streams2/streams3 implementations.

Fixes: nodejs#8828
@addaleax
Copy link
Member

Suggested PR (that does nothing net.Socket-wise, so its desirability is probably up for debate): #8830

@silverwind
Copy link
Contributor

Is it related that process.stdin isn't a ReadStream when redirected?

$ node -p "Object.getPrototypeOf(process.stdin)" | head -1
ReadStream { setRawMode: [Function] }
$ node -p "Object.getPrototypeOf(process.stdin)" < <(echo) | head -1
Socket {

@Fishrock123
Copy link
Contributor

Fishrock123 commented Sep 28, 2016

see: createWritableStdioStream(fd)

jasnell pushed a commit that referenced this issue Oct 10, 2016
Make the internal `SyncWriteStream` a proper `stream.Writable`
subclass. This allows for quite a bit of simplification, since
`SyncWriteStream` predates the streams2/streams3 implementations.

Fixes: #8828
PR-URL: #8830
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
addaleax added a commit to addaleax/node that referenced this issue Oct 11, 2016
Make the internal `SyncWriteStream` a proper `stream.Writable`
subclass. This allows for quite a bit of simplification, since
`SyncWriteStream` predates the streams2/streams3 implementations.

Fixes: nodejs#8828
PR-URL: nodejs#8830
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>
Fishrock123 pushed a commit that referenced this issue Oct 11, 2016
Make the internal `SyncWriteStream` a proper `stream.Writable`
subclass. This allows for quite a bit of simplification, since
`SyncWriteStream` predates the streams2/streams3 implementations.

Fixes: #8828
PR-URL: #8830
Reviewed-By: Matteo Collina <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Jeremiah Senkpiel <[email protected]>

(backport info)
Refs: #9030
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed-bug Issues with confirmed bugs. fs Issues and PRs related to the fs subsystem / file system. process Issues and PRs related to the process subsystem. stream Issues and PRs related to the stream subsystem.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants