I am using node.js and want to handle error messages.
What are the differences between erro, stderr, stdout?
When scripting shell, I redirected stderr and found useful error message and it solved the problem.
I am not clear about the concept of what kind of outputs computer have either. Can anyone explain in a comprehensive way?
Thanks.
It is actually an interesting question. You would probably get more answers if you format the title of your question like this -- Node JS difference between error, stderr, and stdout.
I won't repeat the difference between stdout and stderr, as it is answered previously.
However, the difference between error and stderr is not that easily distinguished.
Error is an error object created by Node JS because it is having a problem executing your command. See more here
Stderr is a standard output stream that happens because something is wrong during execution -- that is Node JS has no trouble executing your command, it is your command itself throws the error.
Let me know if this is clear, otherwise, I'm happy to throw in an example:)
stderr and stdout are streams. Writing to console will log both streams. Apparently the distinction exists between them so we that if we want to (for example) redirect certain data elsewhere, we have the ability to be selective.
You may find the following article helpful.
http://www.jstorimer.com/blogs/workingwithcode/7766119-when-to-use-stderr-instead-of-stdout
Related
Is there a fireproof way to guarantee that all the stdout and stderr in a Node.js process has made its way to the destination (in as much is possible) before allowing a Node.js process to completely terminate?
On some occasions I have consistently seen stdout and stderr fail to make it out of the node.js process before terminating.
What I am thinking is:
process.once('exit', function(){
// use some synchronous call to flush or drain stdout and stderr
});
anyone found a surefire way to do this? Mostly I haven't seen this problem occur, but I am just looking for any possible way that I can add some extra insurance to this.
What is the difference between console.log and process._rawDebug?
This answer tells me that console.log actually calls process.stdout.write with formatting and a new line at the end. According to this article process._rawDebug also writes to the terminal but uses process.stderr. I'm not sure how reliable this article is, though.
I logged 10.000 messages (for testing purposes) to the console using console.log and process._rawDebug. The later was at least twice as fast which should mean something I guess.
Are there any dis(advantages) of using console.log or process._rawDebug? Which one is better/safer to use for logging small messages?
I have found the answer on the Node 0.x archive repository on Github. The commit message description:
This is useful when we need to push some debugging messages out to
stderr, without going through the Writable class, or triggering any kind
of nextTick or callback behavior.
The reason why it is faster is because it bypasses JavaScript entirely and the output is logged directly to the terminal.
I have a python subprocess that runs an arbitrary C++ program (student assignments if it matters) via POpen. The structure is such that i write a series of inputs to stdin, at the end i read all of stdout and parse for responses to each output.
Of course given that these are student assignments, they may crash after certain inputs. What i require is to know after which specific input their program crashed.
So far i know that when a runtime exception is thrown in the C++ program, its printed to stderr. So right not i can read the stderr after the fact and see that it did in face crash. But i haven't found a way to read stderr while the program is still running, so that i can infer that the error is in response to the latest input. Every SO question or article that i have run into seems to make use of subprocess.communicate(), but communicate seems to block until the subprocess returns, this hasn't been working for me because i need to continue sending inputs to the program after the fact if it hasn't crashed.
What i require is to know after which specific input their program crashed.
Call process.stdin.flush() after process.stdin.write(b'your input'). If the process is already dead then either .write() or .flush() will raise an exception (specific exception may depend on the system e.g, BrokenPipeError on POSIX).
Unrelated: If you are redirecting all three standard streams (stdin=PIPE, stdout=PIPE, stderr=PIPE) then make sure to consume stdout, stderr pipes concurrently while you are writing the input otherwise the child process may hang if it generates enough output to fill the OS pipe buffer. You could use threads, async. IO to do it -- code examples.
I have come across strange scenario where when I am trying to redirect stdout logs of perl script into a log file, all the logs are getting written at the end of execution when script completes instead of during execution of the script.
While running script when I do tail -f "filename", I could able to see log only when script has completed its execution not during execution of script.
My script details are given below:
/root/Application/download_mornings.pl >> "/var/log/file_manage/file_manage-$(date +\%Y-\%m-\%d).txt"
But when I run without redirecting log file, I can see logs on command prompt as when script progresses.
Let me know if you need any other details.
Thanks in advance for any light that you all might be able shed whats going on.
Santosh
Perl would buffer the output by default. You can say:
$| = 1;
(at the beginning of the script) to disable buffering. Quoting perldoc perlvar:
$|
If set to nonzero, forces a flush right away and after every write or
print on the currently selected output channel. Default is 0
(regardless of whether the channel is really buffered by the system or
not; $| tells you only whether you've asked Perl explicitly to flush
after each write). STDOUT will typically be line buffered if output is
to the terminal and block buffered otherwise. Setting this variable is
useful primarily when you are outputting to a pipe or socket, such as
when you are running a Perl program under rsh and want to see the
output as it's happening. This has no effect on input buffering. See
getc for that. See select on how to select the output channel. See
also IO::Handle.
You might also want to refer to Suffering from Buffering?.
I have an embedded application that I want a simple-minded logger for.
The system starts from a script file, which in turn runs the application. There could be various reasons that the script fails to run the application, or the application itself could fail to start. To diagnose this remotely, I need to view the stdout from the script and the application.
I tried writing a tee-like logger that would repeat its stdin to stdout, and save the text in a FIFO for later retrieval via the network. Then I naively tried
./script | ./logger
I ended up with only the script stdout going to the logger, and the application stdout disappearing. I had similar results trying tee.
The system is running kernel 2.4.26, and busybox.
What is going on, and how can I accomplish my desired ends?
It turns out it was working exactly as I thought it should work, with one minor gotcha. stdout was being buffered, and without any fflush(stdout) commands, I never saw it. Had I been really patient, I would have suddenly seen a big gush of output when the stdout buffer filled up. A call to setlinebuf(3) fixed my problem.
Apparently, the application output doesn't end up on stdout...
The output is actually on stderr (which is usually also connected to the terminal)
./script.sh 2>&1 | ./logger
should then work
The application actively disconnects from stdin/stdout (e.g. by closing/reopening file descriptors 0,1(,2) or, using nohup, exec or similar utilities)
the script daemonizes (which also detaches from all standard streams)