I got a program which contains a lot of std::cerr, it directly outputs to my terminal. I am wondering what is the difference between std::cerr and std::cout. And how can I disable the std::cerr (I don't want it output to my screen)?
As others have mentioned, if this is a Unix-like system then 2>/dev/null redirects stderr (2) to the big bit bucket in the sky (/dev/null).
But nobody here has explained what the difference between stderr and stdout is, so I feel obligated to at least touch on the topic.
std::cout is the standard output stream. This is typically where your program should output messages.
std::cerr is the standard error stream. This is usually used for error messages.
As such, if your program "contains lots of cerr" output, then it might be worth taking a look at why so many error messages are being printed, rather than simply hiding the messages. This is assuming, of course, that you don't just happen to have a program that emits lots of non-error output to stderr for some reason.
Assuming this program is executed on a *nix system, one possibility is to redirect stderr to /dev/null.
This old newsgroup post shows how to redirect. (code is too large to post here). You need to use streambuf* rdbuf.
cerr is an object of class ostream that represents the standard error stream. It is associated with the cstdio stream stderr.
By default, most systems have their standard error output set to the console, where text messages are shown, although this can generally be redirected.
Because cerr is an object of class ostream, we can write characters to it either as formatted data using for example the insertion operator (ostream::operator<<) or as unformatted data using the write member function, among others (see ostream).
2>/dev/null does the trick. Once again I need to make up the 30 characters.
In many systems, including Windows and Unixes, there are two standard output streams: stdout and stderr.
Normally, a program outputs to stdout, which can be either displayed on screen, or redirected to a file: program > output.txt or redirected as input for another program program1 | program2. For example, you can search in output of your program with the grep tool by running program | grep searchword.
However, if an error occurs, and you print it to stdout which is redirected, the user won't see it. That's why there is the second output for errors. Also the user usually doesn't want error text to be written to the output file, or be fed to grep.
When running a program, you can redirect its error output to a file with program 2>file. The file can be /dev/null, or &1, which would mean redirect to stdout.
Related
I have two loggers in my program. One that I made inside a gui, and one that is super complicated but very well designed and prints to the console. I am trying to get the output from the nice console logger to the rendered one. I have tried everything under the sun to get this to work but I can't seem to figure it out (due to my lack of understanding of the code from the other logger(spdlog).) My conclusion is that taking the logs directly from what is printed is the best way to do this but I can't find online anyone asking how to do this. I have seen a few questions but they just post code as an answer and don't really explain what is going on. My question: Is there a way to grab printed statements from the console and what are the performance issues/complications that come with doing something like this.
For example, if i do std::cout << "hello!" << std::endl; or some printf statement, I want to be able to further down in the code be able to grab "hello!"
My conclusion is that taking the logs directly from what is printed is the best way to do this but I can't find online anyone asking how to do this.
Consoles nowadays are terminal emulators. The original terminals' output went to printers and couldn't be (easily) read back.
Application's stdout and stderr (console) streams are write-only. Moreover, in Windows and Unix/Linux you can pipe your program's (console) output (either or both stderr and stdout) into another application with | (pipe) that creates a pipe IPC between stdout of your application and stdin of another one. That IPC pipe is write-only, your application cannot possibly read back from it.
You may be able to get access to the contents of the frame buffer of Windows cmd.exe that controls its Windows console window, but that won't be the verbatim byte-exact copy of data you wrote into stdout because of the escape sequences interpreted by Windows console.
If stdout is redirected into a file you can re-open that file for reading, but there is no portable way to re-open that file.
In other words, there is no portable way to read console output back.
I have tried everything under the sun to get this to work but I can't seem to figure it out (due to my lack of understanding of the code from the other logger(spdlog).
I bet you haven't tried reading spdlog documentation, in particular logger with multi sinks. A sink is an output abstraction, which implementation can write into a file, memory or both. What you need is attach your own sink to spdlog that prints into your UI.
Derive your sink from base_sink and implement abstract member functions:
virtual void sink_it_(const details::log_msg &msg) = 0; to print into the UI, and,
virtual void flush_() = 0; to do nothing.
Then attach one object of your sink class to that spdlog.
I've got the following code:
std::cerr << "Hello" << std::endl;
std::cerr << "World" << std::endl;
...which would normally be great.
But: I'm running it in an Erlang port program, and Erlang has done ... something to the terminal meaning that "\n" is no longer converted to CRLF, which means that my output is appearing as...
Hello
World
What has Erlang done to my terminal? How do I detect it? How do I get std::endl to output \r\n in this case?
Note: it's (probably) not just that Erlang's ingesting stderr from my program and screwing up the line-feeds. If I use plain-ol' printf("Hello\n") in a NIF, I see the same problem.
Don't use ::std::endl in the first place. It doesn't really do what you want. It always outputs '\n' and flushes the stream. Flushing the stream is a huge and unnecessary performance hit most of the time.
And by '\n' I mean exactly that. An actual, literal,'\n'. It doesn't do any kind of translation or anything that people think it does. Just a flat '\n' and a flush, even on Windows. The newline translation you get under windows is handled by the lower level iostream facilities and is controlled by whether or not the stream is in binary mode.
What Erlang has done to your terminal is probably put it in CBREAK mode. There is a good question or two on here that have answers that describe the differences between raw, cooked, and cbreak terminal driver modes in Unix.
it might be possible for you to manually set your terminal back to cooked mode. The only reason Erlang would have for doing this is that normally you only get what people typed when they hit enter. CBREAK lets you get every character as it's typed.
You can also test yourself what mode the terminal is in. Linux (and later Posix revisions) have apparently replaced the three terminal modes with various flags who's combined effect results in behavior that's very similar to the old terminal modes.
First, you probably want to use isatty(1) (calling isatty on stdout) to see if your output really is a terminal before trying anything else.
Then, you can use tcgetattr to read the current settings for the various bits into a struct termios. This structure contains a member called c_oflag for ouput mode bits. The relevant bits in this case are probably ONLCR, and maybe (but I suspect not) OPOST.
First of all, i'm on Ubuntu 14.04
So, here's my problem: I'm dealing with a C++ coded application that has a graphical interface (games/music players/etc). This application constantly sends strings to a logger whenever something happens, but those are only visible inside the client.
What I've tried to do already (failures):
strace the application and filter the results (let's say if the application showed the message "Hello, user", i would log all the outputs to a test file and search for "Hello")
ltrace the application
debug the application with dbg
search for debug methods on C/C++ apps
What I've got from this last method is that programs usually log errors and messages through a clog stream. What could I do to retrieve that information?
Resuming, I have a graphical C/C++ coded application that constant inputs strings on a window inside the client; I want to read those strings or any other strings/inputs this application does. Any debugging/memory reading information may also be helpful!
Thanks
std::cout corresponds to stdout stream;
std::cerr and std::clog corresponds to stderr stream.
By default, content "sent" to stdout and stderr is displayed in terminal.
To see it, simply open terminal emulator (or, alternatively, terminal), type path where the program is and confirm using Enter. You're going to see content sent to stdout and stderr.
stdout is represented by number 1, stderr by 2.
Next hints are designed to work in bash shell. (they may work on another shells, but they don't have to). If you're not sure you're using bash, type bash in terminal and confirm using Enter.
When you want to send stream's content to file, after path (but before pressing Enter) write space and n>filename, where n is number of stream you want redirect (when skipped, 1=stdout is going to be redirected). By default you won't see redirected content in terminal.
When you want simply completely ignore stream's content, redirect stream to /dev/null.
When you want send stdout to another program (if second program is console program, it's going to see it like entered by user using keyboard), after path (but before pressing Enter) type |program_name and_possible_parameters. You can in example redirect stdout to grep.
grep is going to write only lines containing string passed as argument (after grep, type space and a string, if it contain a space, delimit argument using "" or '', if it contain ' " or \ precede it with backslash (\). If it's result is going to appear in terminal, I recommend to write --color=auto between grep and argument to tell grep to write every occurrence of argument using different color.
Finally, your command can look like
path_to_your_program |grep --color=auto "argument".
You can use more than one redirection in single command.
Redirections are processed from left to right.
When you want to redirect stderr to input of another program, you can redirect it's content to stdout by typing 2>&1 and then use |.
From http://www.cplusplus.com/reference/iostream/cout/:
By default, most systems have their standard output set to the console, where text messages are shown, although this can generally be redirected.
I've never heard of a system where stdout is anything other than a console window, by default or otherwise. I can see how redirecting it might be beneficial in systems where printing is an expensive operation, but that shouldn't be an issue in modern computers, right?
Of course it could be. I may want to redirect standard out to a text file, another process, a socket, whatever.
By default it is the Console, but the are a variety of reasons to redirect it, the most useful (in step with the Unix philosophy) being the redirection of the output of one program to the input of another program. This allows one to create many small, lightweight programs that feed into one another and work as discrete parts of a larger system.
Basically, it's just a simple yet powerful mechanism for sharing data. It is more popular on *nix systems for the reason I mention above, but it applies to Windows as well.
On most systems you can redirect the standard input/output/error to other file descriptors or locations.
For example (on Unix):
./appname > output
Redirects the stdout from appname to a file named output.
./appname 2> errors > output
Redirects stdout to a file named output, and all errors from stderr to a file named errors.
On unix systems you can also have a program open a file descriptor and point it at stdin, such as this:
echo "input" > input
cat input | ./appname
This will cause the program to read from the pipe for stdin.
This is how in unix you can "pipe" various different utilities together to create one larger tool.
find . -type f | ./appname | grep -iv "search"
This will run the find command, and take its output and pipe it into ./appname, then appname's output will be sent to grep's input which then searches for the word "search", displaying just the results that match.
It allows many small utilities to have a very powerful effect.
Think of the >, <, and | like plumbing.
> is like the drain in a sink, it accepts data and stores it where you want to put it. When a shell encounters the > it will open a file.
> file
When the shell sees the above, it will open the file using a standard system call, and remember that file descriptor. In the above case since there is no input it will create an empty file and allow you to type more commands.
banner Hello
This command writes Hello in really big letters to the console, and will cause it to scroll (I am using Unix here since it is what I know best). The output is simply written to standard out. Using a "sink" (>) we can control where the output goes, so
banner Hello > bannerout
will cause all of the data from banner's standard output to be redirected to the file descriptor the shell has opened and thus be written to a file named bannerout.
Pipes work similarly to >'s in that they help control the flow of where the data goes. Pipes however can't write to files, and can only be used to help the flow of data go from one point to another.
For example, here is water flowing through several substations and waste cleaning:
pump --from lake | treatment --cleanse-water | pump | reservoir | pump > glass
The water flows from the lake, through a pipe to the water treatment plant, from the plant back into a pump that moves it to a reservoir, then it is pumped once more into the municipal water pipes and through your sink into your glass.
Notice that the pipes simply connect all of the outputs together, ultimately it ends up in your glass.
It is the same way with commands and processing them in a shell on Linux. It also follows a path to get to an end result.
Now there is one final thing that I hadn't discussed yet in my previous statements, that is the < input character. What it does is read from a file and output it to stdin on programs.
cat < bannerout
Will simply print what was stored in bannerout. This can be used if you have a file you want to process, but don't want to prepend cat <file> because of not wanting to run an extra command in the chain.
So try this:
echo "Hello" > bannerinput
banner < bannerinput
This will first put the string "Hello" in the file bannerinput, and then when your run banner it will read from the file bannerinput.
I hope this helps you understand how redirection and pipping works on Unix (some if not most will apply to Windows as well).
So far all of the answers have been in the context of the thing (shell, whatever) that invokes the program. The program itself can make stdout something other than the terminal. The C standard library provides freopen which lets the programmer redirect stdout in any compliant environment. POSIX provides a number of other mechanisms (popen, fdopen, ...) that gives the programmer even more control. I suspect Windows provides analogous mechanisms.
Any number of things can happen to the three standard file descriptors 0, 1 and 2. Anyone can launch a new process with the file descriptors attached to anything they like.
For instance, GNU screen puts the output into a pipe and allows dynamic reattaching of a session. SSH takes the output and returns it to the other end. And of course all the numerous shell redirectors regularly make use of manipulating the file descriptors.
For a program to have stdout it must be running on a hosted implementation (one with an Operating System), or on a free-standing implementation with extras.
I'm having a hard time figuring such an implementation without a console of some kind, but let's suppose for a moment that Mars Rover has a full OS and is programmed in C (or C++) and doesn't have that console
/* 2001-07-15: JPL: stdout is the headquarters */
puts("Help. I'm stuck.");
might have sent the message to NASA headquarters.
Both Windows and Linux will redirect stdout to a file if you run the program like this:
my_program > some_file
This is the most common case, but many other types of redirection are possible. On Linux, you can redirect stdout to anything that supports the "file descriptor" interface, such as a pipe, socket, file, and various other things.
One simple example of a case where one might want to redirect stdout is when passing the information to another program. The Unix/Linux command ps generates a list of processes that belong to the current user. If this list was long and you wanted to search for a particular process, you could enter
ps | grep thing
which would redirect the stdout of ps to the stdin of grep thing.
I'm writing a console application in which user interaction might be necessary (prompt for keyboard input, cli arguments etc.), but I want to keep it separate from the result of the processing (which goes to cout, in a way that it can be piped to some other application).
How can I achieve this, if I can't just send all interaction with the user to cerr (not everything is an error)?
/dev/tty is the usual way, but it's also possible on most Unix-like operating systems to read from cerr/stderr because the system usually opens the tty once as stdin and dup()s it onto stdout and stderr.
When your stdout is piped somewhere else, the only way to show something on the terminal (apart from maybe things like curses and dialog) is stderr.
If you need user interaction, open /dev/tty, it will be the controlling terminal for the process. Standard error and standard input may be redirected as well.