If I have a code in C# .NET (winforms) which contains a Console.WriteLine("TEST"); and visual studio is attached to the process it doesn't write "TEST" in the output window.
(application is correctly attached)
If I start my program normal with visual studio, it works.
Why does it not work in the first case?
Visual Studio, when debugging windows programs (/target:winexe) will launch them with the stdout and stderr redirected to Named Pipes. The other end of the named pipe is owned by the VS debugger and anything read on these pipes (ie. anything written by the app to stdout or stderr) will be displayed in the Debug Output window (which by no means is the debugged application Output window).
When attach to an application, this redirect can no longer be done (obviously, since the application is already started and stderr and stdin cannot be redirected post-factum). So the Console.Write is no longer auto-magically redirected to the Debug output.
Note that this stdout/stderr redircetion does not occur for console programs (/target:exe)
But there is a dedicated API to write Debug info: Debug.Write. This uses the OutputDebugString functions, which sends text to the attached debugger (if any). This works no matter when or how the debugger is attached, as is not dependent upon stdout/stderr redirection tricks.
Replace your Console.Write with Debug.Write.
Related
My goal is to have it so when the executable is just double clicked no console spawns but also have it able to print to the console when the user launches it from the command line.
I have the following Windows-specific code set to not spawn a console:
#![windows_subsystem = "windows"]
fn main() {
println!("Hello world");
}
Unfortunately, it never hooks stdout/stderr to anything since its set to not create a console on startup. Is there any way to achieve my goal despite this?
This is not really specific to Rust, but instead is the way Windows works: you either write for the "console" subsystem and your program opens a console if it is started without one, or you write for the "windows" subsystem and your program detaches itself from the console if it is started from the command line.
The PATHEXT environment variable — which CLI shells use for the file extensions to add when searching PATH for a command — normally includes ".COM" before ".EXE", in which case one can create a console version of the application with a ".com" file extension (e.g. "app.com"). This can be a standalone version or just a launcher that spawns the main executable (e.g. "app.exe", a GUI app). A launcher can pass a command-line option that allows the main application to attach back to the console via AttachConsole.
Without a launcher, it's a bad idea to attach back to the console since the parent application (e.g. a CLI shell or a full TUI app) normally will not wait for a GUI application to exit, in which case the result is chaotic interleaved I/O with two applications competing for access.
I have a DLL which does as plugin into the TS3 client.
The problem is, the plugin provokes a crash that I cannot seem to find in my code directly.
So my idea is to set the Console Output of the console windows in the background (-console option) to a file, because when the program crashes there is no way I can read the console output as the console disappears immediately.
Is there a way to set the output of a crashing console to a file?
Because so far, when using the stdout operator (ts3client_win64 -console > output.txt) it does not write anything to the file. (I assume it cannot close the file handle and loses all its data?) But I want to keep the console output when the crash occurs.
It also has to be said that I can not just run it with a batch file and a pause statement, because when starting the application it opens its own console window (and thats the one of which I want the output).
It is the type of crash one would get from failed (safe) string operations in C like strtok_s or strcpy_s.
I am trying to control and read the output of a 3rd party console application, of which source code I cannot change.
I want to use QProcess for this, but this should not matter, as the issue is the same when just using cmd:
The 3rd party app seems to never call flush().
Therefore, directly calling it in cmd.exe works fine(Output appears in cmd window), but when calling e.g.
3rdPartyApp.exe > Output.txt
Output.txt stays empty until 3rdPartyApp.exe terminates or quits.
After 3rdPartyApp.exe quits or is terminated, all stdout can be found in Output.txt .
Question:
What can I do to create an environment where the buffer size of the pipe is limited, like when calling directly in cmd.exe, which seems to limit the buffer size to one line?
What you can do is create your own Console type application that will run 3rd party process and "handle" buffering of it.
Then instead redirecting output of 3rd party application, you simply redirect output of proxy console app.
How to do it? You can read it here: https://www.codeproject.com/Articles/16163/Real-Time-Console-Output-Redirection
The author provides explaination and ready to use Console app called RTConsole.exe.
I had big time issue to get unbuffered output from 3rd party pyhton executable spawned from my .NET app and this RTConsole.exe saved me.
Once a debugger (xdebug) is enabled in phpstorm, you can then run your php script (without debugging) from within phpstorm.
How do you view the output of the script in phpstorms console?
I want to see php's output before it gets read by the browser - basically what you would see if you clicked "view source" in the browser.
Here is a video of a jetbrains dev. doing this (2mins:05sec into video) - he just doesnt explain HOW to configure phpstorm to do it.
Currently there is no such option in PhpStorm: to show web server buffer (what was sent to the browser) when debugging web page (note: this should work ONLY when debugging).
Such option did exist for a very short period about 4 years ago (separate Script Output tab in the debugger tool window: http://youtrack.jetbrains.com/issue/WI-2826 ).. but had quite a few issues and it was removed until properly implemented.
http://youtrack.jetbrains.com/issue/WI-18214 --> http://youtrack.jetbrains.com/issue/WI-4466
On that video, especially around 2:05 as you have suggested, ordinary CLI script is executed (Run/Debug Configuration of PHP Script type is used) and therefore ALL such output can be easily caught (standard std output).
With CLI scipt it's easy -- IDE is the parent here (he one who initiated script execution) so std output can easily be collected. If you execute your web page script in CLI environment, you will get your HTML in normal console output.
With web page it works differently (the whole process): script output is first sent to the web server (parent) which in turn sends it to the browser. Since IDE does not directly participate in script execution, such interception can only happen during debugging where debugger can send a copy of collected script output back to IDE.
Most web frameworks buffer the output before sending the results to the webserver. To view the contents of this buffer, first insert a breakpoint at the desired location, then when the breakpoint is reached, then goto the Debug=>Console tab and execute the ob_get_contents() function. PHP's output buffering supported nested levels, so keep this in mind when choosing your breakpoint. Obviously if the CMS/framework doesn't use output buffering then this method doesn't apply.
What is the difference between cscript and wscript? Which is best for doing Telnet and FTP automation in Windows?
In Windows, an executable is either a console application or a Windows application (or a SFU or Native application, but that doesn't matter here).
The kernel checks a flag in the executable to determine which.
When starting using CreateProcess WinAPI function, if it is a console application, the kernel will create a console window for it if the parent process doesn't have one, and attach the STDIN, STDOUT and STDERR streams to the console.
If it is a Windows application, no console will be created and STDIN, STDOUT and STDERR will be closed by default.
WSCRIPT.EXE and CSCRIPT.EXE are almost exactly identical, except that one is flagged as a windows application and the other is flagged as a console application (Guess which way around!).
So the answer is: If you want your script to have a console window, use CSCRIPT.EXE. If you want it to NOT have a console window, use WSCRIPT.EXE.
This also affects some behaviors, such as the WScript.Echo command. In a CSCRIPT.EXE this writes a line to the console window. In WSCRIPT.EXE it shows a messagebox.
For your application I suggest CSCRIPT.EXE. I think you should also look at PuTTY and PLink, and you should also see this here:
Capturing output from WshShell.Exec using Windows Script Host