Currently coding in C++20, using Ubuntu WSL2.
Using the code shown below, the cursor goes invisible when running the program in WSL2 in Windows Terminal, working as intended.
However, when running the program in WSL2 in vscode's integrated terminal, the cursor is visible throughout the whole program (just in case, I even put terminal.integrated.scrollback to 0).
The function curs_set(0) doesn't return ERR when it runs in either of the terminals. Is this a problem with vscode's integrated terminal? Is there a way to fix this?
Code:
#include <ncurses.h>
int main() {
initscr();
noecho();
cbreak();
if (curs_set(0) == ERR) {
addstr("Not working");
}
mvaddstr(1, 1, "Random sentence.");
refresh();
getch();
mvaddstr(2, 1, "Random sentence number two.");
getch();
endwin();
}
I was able to resolve this issue on my end by calling refresh() once first before using curs_set().
I'm having trouble getting a simple C++ script to run in VSCode (I'm new to both). I followed these instructions, and the status bar displays "C++" on the bottom right of the screen, next to the smiley face. I then ran the following script:
#include <iostream>
using namespace std;
main()
{
cout << "Hello World!\n";
return 0;
}
When I run it, the script's path flashes on the output screen and disappears. I expected it to display "Hello World" in the output.
I can run the script from the command window (I'm in Ubuntu) and the output file behaves as expected when executed.
Your program prints message to STDOUT and exits. Add some kind of wait (you can read STDIN for example) if you want to see its output.
PS: Why do you call your program "script"?
Why the program just exits, in vs 2012, while in 2010 does it wait for my input?
#include "stdafx.h"
#include <string>
#include <iostream>
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
string path = "c:\somepath";
cout << "Path is" + path << endl;
getchar();
return 0;
}
The getchar() function is not used in the program flow and only the side effect of waiting for input is used in your case. Instead of hacking your program to avoid closing the window you should use the proper way to keep it open.
Choose one of:
Command window
open a command prompt
navigate to the folder where you want your program to execute
type the path to the .exe and hit Enter. The command prompt is still open after execition of your program and there is not need for getchar().
Start without debugging
just use the menu item Debug->Start Without Debugging. The new console window is still open after execition of your program and there is not need for getchar().
Start with debugging
Set a breakpoint at the closing '}' of your main function.
use the menu item Debug->Start. The debugging session is still active and the window for your console program is still open. There is not need for getchar().
Why you should avoid getchar() to keep a window open?
It's a hack that depends on the program before. There can be some characters in the input buffer a s pointer out here: getchar() doesn't work well?
Your program can't be used in batch file if you come beyond the phase where you try to learn C or C++.
It's not necessary.
I am trying to get my program to log the output of a console application to a text file before it quits. This is a GUI program which launches the console application (tool.exe). The problem is that I am using CTRL + C to quit the console application. This console application cant be altered either. I have tried a few ways of doing this but none have seemed to work ( tool.exe > output.txt ).
Can anyone point me in the right direction of which approach to take ? It would be greatly appreciated.
EDIT:
The file is created but it is empty and does not receive any data. The thing I am after noticing though is if I run the tool from the command line myself, it will work. Eg. c:\>tool.exe > output.txt However this is not working when its executed from my GUI application.
Here is the code I am using to execute the tool:
strcpy (tool, "\" start /D \"");
strcat (tool, toolLocation);
strcat (tool, "\" tool.exe > output.txt\"");
system (tool);
This will run tool.exe and create output.txt fine but will not output anything to the file.
EDIT2:
I think what is actually happening is that because I am using start , the >output.txt is outputing start instead of tool.exe. This would explain why it creates the empty file. Start is just running a fresh command line which is then running tool.exe. The problem is, how do I get around this issue now ?
Try:
#include <signal.h>
void signal_handlerkill(int sig)
{
//Do Soemthing
exit(1);
}
int main()
{
signal(SIGINT, signal_handlerkill); //Connect the interrupt signal (^C) to the function
//Do your code here
return 0;
}
And if that doesn't work, I'd suggest looking here. Specifically:
// crt_signal.c
// compile with: /c
// Use signal to attach a signal handler to the abort routine
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
#include <tchar.h>
void SignalHandler(int signal)
{
printf("Application aborting...\n");
}
int main()
{
typedef void (*SignalHandlerPointer)(int);
SignalHandlerPointer previousHandler;
previousHandler = signal(SIGABRT, SignalHandler);
abort();
}
If you run the application without redirecting to a file, do you see the output you need on the console when you press ctrl+c?
If you don't then there is nothing you can do since you cannot change the application.
Update
What you need is to redirect stdout and stderr to the file. I have never done that but jamesdlin seems to have done that. Take a look at his comment.
What you could try is instead of using start try using cmd.exe directly.
This is the code which managed to solve the problem for me:
char path[500]; //Create character array
strcpy (path, "cd "); //Copy 'cd' into the array
strcat (path, toolLocation); //Copy the path of the tool into the array
strcat (path, " & ip.exe > output.txt"); //Append on the name of the exe and output to a file
system (path); //Run the built array
I am creating a character array and then appending to it. The vital bit here was the & being used in the system call. This is working as an and and first cd'ing to the firectory before executing the .exe.
When using iostream in C++ on Linux, it displays the program output in the terminal, but in Windows, it just saves the output to a stdout.txt file. How can I, in Windows, make the output appear in the console?
Since you mentioned stdout.txt I google'd it to see what exactly would create a stdout.txt; normally, even with a Windows app, console output goes to the allocated console, or nowhere if one is not allocated.
So, assuming you are using SDL (which is the only thing that brought up stdout.txt), you should follow the advice here. Either freopen stdout and stderr with "CON", or do the other linker/compile workarounds there.
In case the link gets broken again, here is exactly what was referenced from libSDL:
How do I avoid creating stdout.txt and stderr.txt?
"I believe inside the Visual C++ project that comes with SDL there is a SDL_nostdio target > you can build which does what you want(TM)."
"If you define "NO_STDIO_REDIRECT" and recompile SDL, I think it will fix the problem." > > (Answer courtesy of Bill Kendrick)
For debugging in Visual Studio you can print to the debug console:
OutputDebugStringW(L"My output string.");
If you have a none-console Windows application, you can create a console with the AllocConsole function. Once created, you can write to it using the normal std::cout methods.
If you're using Visual Studio you need to modify the project property:
Configuration Properties -> Linker -> System -> SubSystem.
This should be set to: Console (/SUBSYSTEM:CONSOLE)
Also you should change your WinMain to be this signature:
int main(int argc, char **argv)
{
//...
return 0;
}
The AllocConsole Windows API function will create a console window for your application.
If you're using Visual Studio, it should work just fine!
Here's a code example:
#include <iostream>
using namespace std;
int main (int) {
cout << "This will print to the console!" << endl;
}
Make sure you chose a Win32 console application when creating a new project. Still you can redirect the output of your project to a file by using the console switch (>>). This will actually redirect the console pipe away from the stdout to your file. (for example, myprog.exe >> myfile.txt).
I wish I'm not mistaken!
Whether to use subsystem:console or subsystem:windows kind of depends on whether how you want to start your application:
If you use subsystem:console, then you get all of the stdout written to the terminal. The trouble is that if you start the application from the Start Menu/Desktop, you (by default) get a console appearing as well as the application window (which can look pretty ugly).
If you use subsystem:windows, you won't get stdout/stderr even if you run the application from a DOS window, Cygwin, or other terminal.
If you want the middle way which is to output to the terminal IF the application was started in a terminal, then follow the link that Luke provided in his solution (http://dslweb.nwnexus.com/~ast/dload/guicon.htm)
For reference, I ran into this problem with an application that I want to run in either normal Windows mode or batch mode (that is, as part of a script) depending on command-line switches. The whole differentiation between console and Windows applications is a bit bizarre to Unix folks!
First off, what compiler or dev environment are you using? If Visual Studio, you need to make a console application project to get console output.
Second,
std::cout << "Hello World" << std::endl;
should work in any C++ console application.
Your application must be compiled as a Windows console application.
There is a good solution
if (AllocConsole() == 0)
{
// Handle error here. Use ::GetLastError() to get the error.
}
// Redirect CRT standard input, output and error handles to the console window.
FILE * pNewStdout = nullptr;
FILE * pNewStderr = nullptr;
FILE * pNewStdin = nullptr;
::freopen_s(&pNewStdout, "CONOUT$", "w", stdout);
::freopen_s(&pNewStderr, "CONOUT$", "w", stderr);
::freopen_s(&pNewStdin, "CONIN$", "r", stdin);
// Clear the error state for all of the C++ standard streams. Attempting to accessing the streams before they refer
// to a valid target causes the stream to enter an error state. Clearing the error state will fix this problem,
// which seems to occur in newer version of Visual Studio even when the console has not been read from or written
// to yet.
std::cout.clear();
std::cerr.clear();
std::cin.clear();
std::wcout.clear();
std::wcerr.clear();
std::wcin.clear();
I assume you're using some version of Visual Studio? In windows, std::cout << "something"; should write something to a console window IF your program is setup in the project settings as a console program.
If using MinGW, add an option, -Wl,subsystem,console or -mconsole.
You don't necessarily need to make any changes to your code (nor to change the SUBSYSTEM type). If you wish, you also could simply pipe stdout and stderr to a console application (a Windows version of cat works well).