# Method of viewing command prompt on remote machine without locking it for local use

I need to remotely view/access an already running command prompt on another computer (it was started by that computer locally). The OS of the local machine is windows 7 32 (or 64) bit.

Programs such as gbridge, ultraVNC and the windows remote desktop will not work, because the process running on the machine will slow down if I view anything other than just the terminal (there are several movie captures happening that I don't want to drop in frame rate).

I also do not want to lock the remotely accessed computer. Is there some feature of a common program that will allow me to remotely view just the command prompt of the remote computer without compromising the frame rate of the computer?

This will all be done with a VPN within a secure network, so I am not extremely concerned if part of the solution includes plain text.

Is there a method that anyone knows of to accomplish this? Questions welcome.

• Maybe alter the command which invokes the command prompt to redirect its standard out to a file. You could then read the output file without having to initiate any heavy-duty remote access apps; just transfer the text file over the network somehow (SMB, FTP, HTTP, whatever; it's just text.) Using something like Wintee (Windows port of the Unix tee utility) you could direct output both to the screen (as normal) and to your file. – Andrew Lambert Mar 2 '12 at 18:02
• @Amazed That is a great idea! Thanks. If you post below I will give you the check. – St-Ste-Ste-Stephen Mar 5 '12 at 16:43
• I posted it and expanded a bit, too. – Andrew Lambert Mar 6 '12 at 0:27

You could alter the command which invokes the command prompt on the remote machine to redirect its standard out to a file. This is done by specifying > C:\path\to\logfile.log or >> C:\path\to\logfile.log as the last command in a command line. The > operator creates a new file always, overwriting the old one , if any. The >> operator creates a new file if needed and appends the data to the file. Appending is obviously useful if you don't want old output destroyed every time the script runs.

You could then read the output file without having to initiate any heavy-duty remote access apps; just transfer the text file over the network somehow (SMB, FTP, HTTP, whatever; it's just text.) Using something like Wintee (Windows port of the Unix tee utility) you could direct output both to the screen (as normal) and to your file.

Depending on your network setup, you may be able to redirect output to a file on a remote network share. This has the obvious advantage of not requiring you to log into the target machine at all since the log of its output lives on a server or on a shared folder on your computer. For example:

   C:\>echo "Begin Log" >> \\Server123\Shares\logfiles\log1.log


Bad things may happen if the network location is unreachable or on a high-latency connection, such as noticeably increasing run time for the script or failing altogether if the remote path is invalid or unavailable. It may be preferable to store the log locally and then use the Task Scheduler (or other automation tool) to copy the log(s) to a remote network location.

On Unix, the canonical way to do something like this would be to use a terminal multiplexor like GNU screen or tmux.

So on Windows, you might consider running an sshd service under Cygwin, and then running your program under GNU screen (tmux doesn't currently work under Cygwin). There is a prebuilt screen package for Cygwin. You can use the -x option to screen to display the terminal session in multiple locations.

• I do love screen, but I cannot use Cygwin on this machine unfortunately. – St-Ste-Ste-Stephen Mar 5 '12 at 16:43