node.js, console.log and stderr
1,352 views
Skip to first unread message
jon.seymour
Apr 17, 2011, 7:25:42 PM4/17/11
to nodejs
As I understand the idiomatic use of console.log in JavaScript it is
meant to be used for sideband information - diagnostic output,
information, warning and error messages.
By default, node.js binds console.log to stdout.
This seems to be against the long standing unix best practice of
reserving stdout for structured data, and using stderr for diagnostic
output and other sideband info.
The current practice means that someone who aggregates a program from
a large number of node.js modules will never be quite sure whether the
contents of stdout can be trusted. Some module, somewhere, might
decide sometimes, to write something to console.log and then game over
for anything downstream of the node.js process in a unix pipeline.
Now, I understand that if one cares, one can override console.log with
one's own function that writes to stderr. However, if everyone starts
doing that, the ability of debuggers to intercept console.log for
their own purposes will be severely compromised.
This is call for a standard way to tell node.js to use stderr for
console.log output. If you don't care about breaking this, then it
should be the default behaviour. If it isn't the default, it should be
configurable as the default or at least accessible via command line
switch.
meant to be used for sideband information - diagnostic output,
information, warning and error messages.
By default, node.js binds console.log to stdout.
This seems to be against the long standing unix best practice of
reserving stdout for structured data, and using stderr for diagnostic
output and other sideband info.
The current practice means that someone who aggregates a program from
a large number of node.js modules will never be quite sure whether the
contents of stdout can be trusted. Some module, somewhere, might
decide sometimes, to write something to console.log and then game over
for anything downstream of the node.js process in a unix pipeline.
Now, I understand that if one cares, one can override console.log with
one's own function that writes to stderr. However, if everyone starts
doing that, the ability of debuggers to intercept console.log for
their own purposes will be severely compromised.
This is call for a standard way to tell node.js to use stderr for
console.log output. If you don't care about breaking this, then it
should be the default behaviour. If it isn't the default, it should be
configurable as the default or at least accessible via command line
switch.
mscdex
Apr 17, 2011, 10:57:05 PM4/17/11
to nodejs
On Apr 17, 7:25 pm, "jon.seymour" <jon.seym...@gmail.com> wrote:
> This is call for a standard way to tell node.js to use stderr for
> console.log output. If you don't care about breaking this, then it
> should be the default behaviour. If it isn't the default, it should be
> configurable as the default or at least accessible via command line
> switch.
FWIW there is console.error for writing to stderr, but output to
> This is call for a standard way to tell node.js to use stderr for
> console.log output. If you don't care about breaking this, then it
> should be the default behaviour. If it isn't the default, it should be
> configurable as the default or at least accessible via command line
> switch.
stderr is blocking (unlike console.log).
P. Douglas Reeder
Apr 17, 2011, 11:16:18 PM4/17/11
to nodejs
On Apr 17, 7:25 pm, "jon.seymour" <jon.seym...@gmail.com> wrote:
> As I understand the idiomatic use of console.log in JavaScript it is
> meant to be used for sideband information - diagnostic output,
> information, warning and error messages.
>
> By default, node.js binds console.log to stdout.
I would say that, for server programs, the main output is over the
> meant to be used for sideband information - diagnostic output,
> information, warning and error messages.
>
> By default, node.js binds console.log to stdout.
network, and stdout _is_ the sideband.
Jon Seymour
Apr 17, 2011, 11:53:41 PM4/17/11
to nod...@googlegroups.com
I agree with that statement for servers. I guess my interest currently
is using node.js in unix pipelines where this is not true.
Does any standard specify the behaviour and capabilities of console?
What would a convention of rebinding console.log to stderr look like?
Should it be up to every top-level app to decide, or should there be
support in the node API itself?
jon.
Jon Seymour
Apr 18, 2011, 12:00:10 AM4/18/11
to nod...@googlegroups.com
Thanks for that information. I guess the issue remains that the java
script idiom is to use console.log for unstructured sideband info and
this conflicts with a desire to use node.js in a unix pipeline.
I think it wuld be a big ask to get module writers to stop using
console.log for this sort of information, but it would be a shame if
node.js neutered itself as a unix pipeline component because of this
problem. So, it would be nice if there was a standard way to resolve
the issue.
jon.
mscdex
Apr 18, 2011, 1:17:48 AM4/18/11
to nodejs
On Apr 18, 12:00 am, Jon Seymour <jon.seym...@gmail.com> wrote:
> I think it wuld be a big ask to get module writers to stop using
> console.log for this sort of information, but it would be a shame if
> node.js neutered itself as a unix pipeline component because of this
> problem. So, it would be nice if there was a standard way to resolve
> the issue.
>
> jon.
Usually when I write a module, I let the user pass in their own debug
> I think it wuld be a big ask to get module writers to stop using
> console.log for this sort of information, but it would be a shame if
> node.js neutered itself as a unix pipeline component because of this
> problem. So, it would be nice if there was a standard way to resolve
> the issue.
>
> jon.
function during configuration/setup (via the constructor or
otherwise), that way they can choose how to handle the information.
Mark Hahn
Apr 18, 2011, 2:03:49 AM4/18/11
to nod...@googlegroups.com
I was spawning child processes and communicating with them using the provided stdin, stdout. It worked great until I added a module that did exactly what you are complaining about. I embedded escape sequences into my streams to tell the real data from the sideband.
I should switch to using intra-host net connections or pipes. I assume that would perform a lot better than scanning the data.
Which would use the least resources, unix pipes or net connections? Or would they be the same?
Reply all
Reply to author
Forward
0 new messages