I'm attempting to develop a coprocess plugin in python for iTerm2 but am running into some issues. I have a script that takes input from STDIN and sends it across the network to a listening daemon. This works fine when run from the command line, however when I activate the coprocess either via the menu or a trigger I just see a brief flash of the coprocess icon in the upper right corner. Googling does not reveal whether or not iTerm2 sends output anywhere that I can examine. I have looked at all of the system logs in Console.app but there is nothing there. I've also tried Toggling the Debug Logging in iTerm but I do not see any coprocess data in there. Anyone know if/where to find the STDOUT/STDERR of a coprocess script?
Stdin and stdout are hooked up to the tty as described in copresses documentation (and may be silent or visible depending on how it is set up). As for stderr, (judging by the lack of any redirect of fd 2 in Coprocess.m source) it is the same as stderr of iTerm2 itself. In order to see the error of copresseses, you can launch iTerm2 from Terminal in the foreground (open /Applications/iTerm.app/Contents/MacOS/iTerm2), interact with iTerm2, and view the stderr within Terminal.
Related
I have a "hello world" Windows desktop application, the source of which comes from this official walkthrough.
When I run this program from Windows Subsystem for Linux, I get behavior I expect: the shell blocks, waiting for the process to exit, and the shell prompt only re-appears once the process has exited. I can then inspect the process exit code (here set to 3, by returning this from wWinMain):
jim#LAPTOP-SMUS1UJN:/mnt/c/Users/james/source/repos/DesktopApp/x64/Release$ ./DesktopApp.exe # blocks until I close the window ...
jim#LAPTOP-SMUS1UJN:/mnt/c/Users/james/source/repos/DesktopApp/x64/Release$ echo $?
3
However, this is not the behavior I get when running the program from Command Prompt or from PowerShell. Here, the process starts, but the shell claims that the process immediately exited, giving me a new prompt immediately! But the process has clearly not exited, because the window it created still exists and I can interact with it.
In both cases (Windows Subsystem for Linux, and PowerShell), the process stdout is not printed to the terminal. (Verified with std::cout << "test", which prints nothing to the terminal.)
It's as if the original process has spawned a daemon process to run the win32 stuff. But I don't think that is what's happening, because Windows Subsystem for Linux at least blocks until exit.
When I create a "console" C++ application with Visual Studio, it behaves as expected. The strange early-exit-with-no-output behavior only happens for my "desktop" win32 program.
So, why does Command Prompt or PowerShell claim that the process exits immediately? And where is its stdout?
Jonathan Potter provided the crucial pointers in a comment on the question; to elaborate:
Any given Windows application falls into one of these two mutually exclusive categories[1]:
GUI-subsystem applications, such as Notepad.exe:
Such applications typically create GUI windows, and sometimes no UI at all.
Due to not being associated with a console, they cannot write to the standard output (stdout) or standard error (stderr) streams.[2]
Console-subsystem applications, such as findstr.exe:
Such applications either create a console window when invoked, or run in a preexisting one, typically one created by a command-line shell such as cmd.exe or PowerShell.
They write output to the standard output (stdout) and/or standard error (stderr) output streams.
(Console-based) command-line shells on Windows, such as cmd.exe and PowerShell:
invoke console-subsystem applications synchronously and report their exit code: via pseudo environment variable %ERRORLEVEL% in cmd.exe, and via variable $LASTEXITCODE in PowerShell.
Additionally, the stdout and/or stderr output from such application is printed to the console by default, but can also be captured, redirected, or passed to other console-subsystem applications via a pipeline.
invoke GUI-subsystem applications asynchronously by default, launch-and-forget-it style.
That is, the shell by default neither waits for the application process to finish, nor does it report its exit code.
However, both shells offer synchronous invocation, including exit-code reporting, on an opt-in basis:
In cmd.exe, use start /WAIT ... for both synchronous execution and having the exit code reflected in %ERRORLEVEL% afterwards; see the internal start command's documentation.
In PowerShell, use Start-Process -Wait ... for synchronous execution; to also get the process exit code, use $ps = Start-Process -Wait -PassThru ..., and then examine $ps.ExitCode - see the Start-Process cmdlet's documentation.
By contrast, the POSIX-like shells of WSL (the Windows Subsystem for Linux), such as, by default, bash:
invoke both console-subsystem and GUI-subsystem applications synchronously by default, and reflect the exit code of either application type in the built-in $? variable afterwards.
To opt-into asynchronous invocation, use postpositional & to perform the invocation from a background job; e.g., (Notepad.exe &)
Note: (...) suppresses the shell's job-control status message that & triggers (effective in bash, zsh, and dash, but not ksh); see this answer for details.
[1] The GUI and the console subsystems are the relevant ones for executables designed to be run by end users directly. Other subsystems exist, as described in this help topic on the PE format (the format of executable files on Windows). Tip of the hat to James (the OP) for providing the link.
[2] While GUI-subsystem applications can explicitly create a console on demand, such a console is independent of the console of a console-subsystem caller. It is even possible to attach to the preexisting console of a console-subsystem caller, but the caller will have no awareness of this, and will therefore not be able to capture, redirect, or pass on any output written to that console by the GUI-subsystem application.
In some cases, the Trace32 may hang, or may be closed while the target core is still running. This leads to the following screen when trying to reopen the Trace32 GUI:
Is there any way to force a "Reset and connect" (choose "Yes" in the popup) using the command-line, without requiring human interaction?
Short answer:
add the line
CONNECTIONMODE=AUTOCONNECT
to the PBI= section of you TRACE32 configuration file (usually "config.t32")
E.g.:
PBI=
USB
CONNECTIONMODE=AUTOCONNECT
Note: The block starting with PBI= must be embraced by empty lines, while there mustn't be empty lines within the block.
Detailed answer:
If you see that dialog box one of the following has happened:
You have started a second TRACE32 for an AMP multicore scenario, but the second GUI wasn't configured with CORE=2 or the first GUI wasn't configure for CORE=1.
You've started TRACE32, while another TRACE32 GUI is still exclusively connected to the same PowerDebug box.
You've started TRACE32, after the process or a TRACE32 GUI was killed (process removed from execution without proper closing the application).
You've started TRACE32, after a previous TRACE32 GUI crashed.
So in general you shouldn't see the dialog box and something went wrong, when it happened.
In case of issue 1 & 2 you should click NO, solve the issue as described below and then try it again. If you click YES, you will crash the already running TRACE32 GUI.
In case of issue 3 & 4 you could safely click YES, but anyway you should ensure that TRACE32 gets normally not killed (and crashes should be fixed by the Lauterbach support, I guess)
If you want TRACE32 to automatically "click" NO, to immediately close the new TRACE32 session, use the statement CONNECTIONMODE=AUTOABORT in the PBI= section of your TRACE32 configuration file (usually "config.t32"). (See also /pdf/installation.pdf)
If you want TRACE32 to automatically "click" YES, to force connection to the PowerDebug box by resetting it, use the statement CONNECTIONMODE=AUTOCONNECT in the PBI= section of your TRACE32 configuration file (usually "config.t32"). (See also /pdf/installation.pdf)
You can set this also in T32start, if you connect to you PowerDebug via Ethernet (e.g. PowerDebug PRO):
Note: In T32Start, this setting is only available if you connect to a PowerDebug via Ethernet (e.g. PowerDebug PRO). The setting CONNECTIONMODE=AUTOCONNECT/AUTOABORT works also with USB, but there, you have to add it manually to your TRACE32 configuration file.
And here is how to avoid the dialog box:
Case 1 "You have started a second TRACE32 for an AMP multicore scenario..."
For AMP multicore debugging with one TRACE32 GUI per core, please ensure that you setup a proper AMP scenario: Add the line CORE=n to the PBI= section of you TRACE32 configuration file (usually "config.t32"), where n must be 1 for the 1st GUI, 2 for the 2nd GUI, 3 for the 3rd GUI,...
If you starting TRACE32 via T32start.exe you have to set it up like that:
Case 2 "Another TRACE32 GUI is still exclusively connected to the same PowerDebug box"
Before starting a new TRACE32 GUI connecting to a PowerDebug box, please ensure to close all other TRACE32 GUIs you've started before (for the same box). You can do this from a system shell via t32rem.exe, if you know the remote-API port of the other GUI: t32rem localhost port=<API-port-of-GUI> QUIT (See also How to start and close Trace32 instances from t32start command line interface? on more details how to do that)
I am using TRACE32 R.2021 version. I have faced same issue like "TRACE32 device already used by other GUI"
I have added the following configuration in config_multicore.t32(Config file in my version of workspace)
CONNECTIONMODE=AUTOCONNECT
The issue got resolved.
Change the Connect Mode to Auto-Connect from Normal. Jtag should get reset on changing configuration
enter image description here
I'm developing a chat server in C++. The programme is built and run from a terminal. As running in the terminal, I can write to this terminal normally using 'printf'. Some of the information written to this terminal are the alerts of new incoming connections, outgoing connections, etc.
Now I need to get the keyboard input so that admin can type commands to see the values of variables in the chat server. I intend to create a new thread and attach a new terminal to it. A suggestion is to call system("gnome-terminal"), but it requires a little delay with sleep(), doesn't seem to be a good choice because all the contents redirected to this gnome-terminal will be considered as bash commands. And I don't know how to attach the terminal opened by 'system'` command to the thread.
Any simple way to attach a terminal to created thread?
Maybe have a read of this on how to use pipes in Linux
http://linuxprograms.wordpress.com/tag/pipes/
As partially answered in this question: Avoid gnome-terminal close after script execution?
There is a good option like this:
(1) Use the main terminal for normal input/ouput.
(2) Create log file (log.file) before calling 'tail'
(3) Use 'tail' command for showing log contents (log files)
//c++ code
system("gnome-terminal -e \"bash -c 'tail -f log.file'\"");
(4) Append the content to 'log.file' to tell 'tail' to show it up.
I want to know how to programmatically execute commands (like "dir C:\" or "shutdown -r", etc.) in Windows' Command Prompt (CMD) and retrieve the resulted output, without displaying the black CMD window of course.
I suspect ->this link<- contains the list of required APIs, but I'm not sure which ones to pick, so need your assistance.
Basically this is what I need it for: I want to write simple client-server application (WinSock) where user can sit on the client end and execute commands in (and read replies from) the command prompt of server. Yes - just like Telnet works, but without Telnet, just Win32 API.
Suppose user wants to execute "dir" command on server. He types "dir" on client application, which sends request to the server application, where the command will be executed (as if it was physically typed in command prompt of server) and the output text will be sent back to the client application.
You are basically trying to reimplement one of the many possible uses of netcat. By running on the windows system in a command prompt:
nc -l -L -e cmd -p 5555
and then running from another system
nc 192.168.1.xxx 5555
with 192.168.1.xxx being the IP address of the windows machine you can do exactly what you are talking about: whatever you type will be "typed" on the windows machine and you will get the output from the remotely executed commands. You can also run netcat in an hidden window.
Note that because of this feature some antivirus blocks the netcat program... it has been apparently used by malicious software to transform PC of victims into slave bots.
Note also that routing input/output directly to cmd (the XP shell) is extremely dangerous as there is no authentication of any type: anyone can connect to port 5555 and execute commands on the machine, something you really don't want to allow unless you're in a very controlled environment.
Although this answer is not a good one for portable software, it works exactly the way you need it if you are sure everything is ok:
int system(const char *command);
This function executes command in shell (CMD in windows) if available.
By "if everything is ok" I mean you have a shell in your OS and it is available to you. Generally, this should be true for windows.
If you call it with NULL, it will give non-zero if shell is available. If you give an actual command, it either returns -1 indicating an error (for example couldn't spawn a process), or return status of the command which should be OS dependent. Perhaps what you would be most concerned with is "if the command failed" and you should be good by checking the return value against 0 (0 being good).
Note that to get the output of the command, and you need to save the output somewhere. For example execute the dir command like this:
error = system("dir > temp.txt 2>&1");
and then retrieve its output from temp.txt.
I have written a simple program that pings three sites and then reacts to whether they are reachable or not.
My question is: can I suppress system("ping ")'s output? I have written my code in C++ as I know that language the best. Currently the code opens the ping.exe running the system command. If I can prevent the output from showing up while it still pings that would be ideal.
I am eventually going to turn this program in a windows service that is why I would like to suppress both the command line console window as well as suppress the ping output. Thanks.
Try doing system("ping host > nul") (nul is windows equivalent of UNIX /dev/null).
Generally, if you're going to call another program but don't want it to act like std::system, you're going to need a platform-specific function like fork()/exec() on UNIX or CreateProcess() on Windows. These functions give you control over how the other program runs, for instance, that it not show output or not create a console window, etc.
You can use system command like below to suppress the output of ping command.
system("ping 100.100.100.100 > response.dat");
Above command pings IP address 100.100.100.100 and directs the output to a file called response.dat. In response.dat you can see the response of ping command.
Do system( "ping site.com >nul 2>nul" ); and check the value the shell returns.
if the ping succeeds, the shell will return 0, else it will return 1.
I would be more detailed, but Vis Studio is reinstalling itself. :)
There's also a way to hide the console window using the Win API to exec the command, but...
I do not remember the details.
Edit:
I'm still waiting for the MSVS install process, so... :)
Use CreateProcess with the DETACHED_PROCESS flag for the dwCreationFlags parameter to hide the console window.
After you call create process, you'll have to use WaitForSingleObject on the process handle to wait for the ping to complete. The last parameter to CreateProcess should have a pointer to process information that contains the process handle. (Assuming CreateProcess was successful) You have to wait for the command to complete. Once it's complete, you can use the process handle to get the return value, though I'm too time contstrained to tell you how to do that at this point.
When you get over to Windows and call CreateProcess(), be sure to set:
lpStartupInfo->wShowWindow = SW_HIDE;
This will ensure that any windows created by the new process are hidden.
Using the DETACHED_PROCESS flag will prevent the new process from inheriting your application's console, but that does not prevent the new process from creating a new console. Not sure what ping would do, but best to remove all doubt by using SW_HIDE.
You could also use this way, this will return the output in a file and doesn't show up a console windows and freezes the main application which is really usefull.
At first you need to include the Windows header using;
#include <Windows.h>
then send a ping command and write the output into a file like this;
WinExec("ping google.com > file.dat", SW_HIDE);
This will send a ping command to google.com and writes the output to the file 'file.dat' in the directory of your current running program. So you could change file.dat to any file or filepath you want and of course you could change the ping command. The > character means that the output of the command needs to be wrote in the file path behind it.
If you want to show the console window and freeze the application while running the ping command you need to use the following line of code instead of the WindExec() code;
system("ping google.com > file.dat");