During compilation process many errors are thrown on the screen. To start resolving them I need to scroll up 3, 4 pages. I tried doing head on them but they still came on the terminal.
g++ -std=c++0x testCoverDownloader.cpp -I /usr/include/QtCore/ -I /usr/include/QtGui 2>&1 | head
how to I just see the top errors first and then scroll down the page? The code above cuts the output to show the top 10 lines. What I want is all errors but from the start so that I dont need to scroll upwards
As well as using 2>&1 to get the STDERR results to STDOUT, you might want to try tee in order to get the results into a file for later viewing.
If you use vim you could try <your compile statement> 2>&1 | vim - That should pipe STDERR and STDOUT to vim for viewing.
EDIT:
Added in #joachim pilberg's comment to provide a more accurate answer:
The important part is the redirection part: Error from the compiler is
put on stderr. To pipe it to head, a viewer like more or less or even
an editor like vim, you need to redirect stderr to stdout. This is
what is done with the &2>1 (or more correctly 2>&1). See the manual
page of your shell for more information about redirection.
you can also add -Wfatal-errors compiler option to stop compilation after first error
Related
So I tried somthing like this:
g++ long_error_code.cpp | less
That didn't work. I also tried redirecting to a file, but that also didn't work. So how does one handle those long error messages besides mouse scrolling thru it?
I would like a quick way to be able to move thru it and be able to search patterns like the way the command less works.
In a normal shell you can use:
g++ foo.cpp 2>&1 |less
The >& shell operator means to redirect the left-hand stream into the right-hand one, so this ends up with stream 1 (stdout) containing the lines that were originally in stream 2 (stderr) as well. The | operation takes stream 1 of the left operand as the input for the right operand.
According to this, the Bash shell also allows g++ foo.cpp |& less .
I have a c++ program that run a command and pass some arguments to it. The code is as follow:
int RunApplication(fs::path applicationPathName,std::string arguments)
{
std::string applicationShortPath=GetShortFileName(applicationPathName);
std::string cmd="\""+applicationShortPath +"\" "+ arguments+" >>log.txt 2>&1 \"";
std::cout<<cmd<<std::endl;
int result=std::system(cmd.c_str());
return result;
}
When I run system command, the cmd window appears shortly and then closes, but the result is 1 and the cmd was not run (the command should generate output which is not generated).
To check that the cmd is correct, I stopped the application just before system line and copy/ paste cmd content to a cmd window and it worked.
I am wondering how can I find why application is not run in system()?
the cmd has this value just before running it:
"D:/DEVELO~3/x64/Debug/enfuse.exe" -w --hard-mask --exposure-weight=1 --saturation-weight=0.328 --contrast-weight=0.164 -o "C:/Users/m/AppData/Local/Temp/1.tif" "C:/Users/m/AppData/Local/Temp/1.jpg" "C:/Users/m/AppData/Local/Temp/2.jpg" >>log.txt 2>&1 "
How can I find why it is not working?
Is there any way that I set the system so it doesn't close cmd window so I can inspect it?
is there any better way to run a command on OS?
Does Boost has any solution for this?
Edit
After running it with cmd /k, I get this error message:
The input line is too long.
How can I fix it other than reducing cmd line?
There are two different things here: if you have to start a suprocess, "system" is not the best way of doing it (better to use the proper API, like CreateProcess, or a multiplatform wrapper, but avoid to go through the command interpreter, to avoid to open to potential malware injection).
But in this case system() is probably the right way to go since you in fact need the command interpreter (you cannot manage things like >>log.txt 2>&1 with only a process creation.)
The problem looks like a failure in the called program: may be the path is not correct or some of the files it has to work with are not existent or accessible with appropriate-permission and so on.
One of the firt thing to do: open a command prompt and paste the string you posted, in there. Does it run? Does it say something about any error?
Another thing to check is how escape sequence are used in C++ literals: to get a '\', you need '\\' since the first is the escape for the second (like \n, or \t etc.). Although it seems not the case, here, it is one of the most common mistakes.
Use cmd /k to keep the terminal: http://ss64.com/nt/cmd.html
Or just spawn cmd.exe instead and inspect the environment, permissions, etc. You can manually paste that command to see whether it would work from that shell. If it does, you know that paths, permssions and environment are ok, so you have some other issue on your hands (argument escaping, character encoding issues)
Check here How to execute a command and get output of command within C++ using POSIX?
Boost.Process is not official yet http://www.highscore.de/boost/process/
When I execute this command (where fail.cpp is a simple program filled with compiler errors), the errors are not output directly on the screen, but, rather, within the fail.out file:
g++ fail.cpp > fail.out 2>&1
From my introductory understanding of bash, this makes sense: > redirects the program output (stdout, a.k.a. 1) to fail.out, while 2>&1 redirects stderr (a.k.a. 2) to this new place for stdout, which is the file. (?)
But changing the order of the command makes things happen differently:
g++ fail.cpp 2>&1 > fail.out
Now, the error messages go directly onto the screen, and fail.out is a blank file.
Why is this? It seems like the same idea as above: redirect the errors that this command will produce to stdout (2>&1), and redirect that, in turn, to the fail.out file. Is it an order of operations thing that I am missing?
2>&1 means "redirect stderr to where stdout is currently connected", and redirections are processed in order from left to right. So the first one does:
Redirect stdout to the fail.out file.
Redirect stderr to stdout's current connection, i.e. the fail.out file
The second one does:
Redirect stderr to stdout's current connection, i.e. the terminal.
Redirect stdout to the fail.out file.
I have a quick question, should be relatively simple for those who have some more experience in WMI-command processor than I do (and since I'm an absolute beginner thats not hard :-) )
I fail to understand why wmic /format switch works the way it does. I open up cmd.exe and type
wmic process list brief /format:htable > processlist.html
this does exactly what I want and no bothers further on. Whereas if I go to wmic processor, and try to execute the same command exactly as above...
wmic:root\cli>process list brief /format:htable > processlist.html
I receive the error tag: "Invalid XSL format (or) file name."
Here goes the screenshot. Note I have already copied XSL files from wbem to sys32 dir
Can someone explain to me why these 2 commands that for me look exactly the same, with the only difference that one is executed outside wmic environment and the other one is from inside, the latter one doesn't work? I just fail to understand it.
Please advise so I can comprehend this a bit better! :-)
Try this
copy /y %WINDIR%\system32\wbem\en-US\*.xsl %WINDIR%\system32\
And then
wmic:root\cli>process list brief /format:htable.xsl > processlist.html
Note the presence of the extension after "htable"
You are attempting to use CMD.EXE > redirection while you are within the interactive WMIC context. That can't work.
You can use the WMIC /output:filename switch while in interactive mode. Each subsequent command will overwrite the output of the previous command. You can get multiple commands to go to the same file by using /append:filename instead. You can reset the output back to stdout using /output:stdout.
/output:processlist.html
process list brief /format:htable
/output:stdout
Did you try specifying a full path in the wmic:root\cli>process call? My bets are that the first worked because it output the file to the current directory.
this code print but i need see all line with scroll
#include "iostream"
#include "conio.h"
using namespace std;
void main()
{
for (int k=1 ;k<1000;k++)
cout<<k<<"\n";
getch();
}
i write in windows seven
when compile and see result only 300 line i see 701-999
butt i need see all line 1-999
If you are on Linux:
g++ filename.cpp -o filename.out
./filename.out | less
I don't use Windows, so I can't say if there is an equivalent.
Scrolling of the output is a feature of the console window itself. If your console window doesn't support scrolling, you won't get it with your code, unless you reimplement the console window yourself.
Beside that, your code correctly writes out 999 lines. I would however replace "\n" with endl.
Just pipe the output to a file and view the file with a program that has paging capabilities such as less, eg. ./a.out > test.txt; less test.txt
Typing
./yourprogram | more
after compiling it should do the trick. There's no other way to do this, unless you pause your output programatically. You can also use
system("pause");
in your code after every 50 lines or so, but this is not recommended and works on Windows/DOS only.
In addition to misha's answer, you can use more in a Windows terminal.
MyProgram | more
more is also a Unix command, but I think DOS's more works more like the Unix less (which lets you go up as well as down thorugh the output) iirc.