Access watch variables from trace32 scripting language - c

I'd like to create a diagnosis script and would like somehow to get all the variables the user inputs in a watch window to a script. How may i access the watch variables and manipulate them?
I tried with a DIALOG.view but that wastes too much time. There might be another trace command but I don't know it. Thank you!

Getting the content of open Var.Watch windows from script is not directly supported in TRACE32.
However you can do the following in you script
Redirect printing to a file PRinTer.FILE "~~~/winpage.txt" ASCIIE (of course you can choose any other filename instead of winpage.txt)
The window WinPAGE.List shows you all open child windows. With WinPrint.WinPAGE.List you can sent the list of all open windows to the file specified before (winpage.txt).
Now parse the content of winpage.txt for the names of the windows, which are a watch windows. The window names start by default with a capital 'W' followed by three decimal digits (but can also be totally different) and are then followed by the command (in round brackets) which was used to open the windows. Compare case insensitive!
The watch windows have a command which starts with:
B::Var.Watch
B::V.Watch
B::Var.W
B::V.W
Redirect printing to a new file e.g. PRinTer.OPEN "~~~/varwatch.txt" ASCIIE
Send the content of each open watch window to the file varwatch.txt with the command WinPRT <window name>. The relevant window names you've got from step 3. Execute WinPrt for each open watch window.
Close varwatch.txt with PRinTer.CLOSE
Now you should have the content of all open watch-windows in the file varwatch.txt.
Other idea:
Use command STOre "mywindows.cmm" Win to save commands to create all open windows to a script.
Parse this script for all lines starting with Var.Watch (or one of it's shorts forms) and the lines starting with Var.AddWatch (or one of it's shorts forms). Parse case insensitive!. The arguments followed by Var.Watch or Var.AddWatch are the variables currently shown in the watch windows.

Related

How to enable logging in xterm

Is it possible to turn on logging feature by default in xterm?
Lets say for example, I have example program in c that give an output in xterm everytime i ran the program from default bash terminal in linux. And I want to save the output that shows in xterm into a file everytime the programs is run.
I'm using centos7_x86_64 fyi
Thanks.
In Windowmaker:
Hold down ctrl + left click in xterm window (on the terminal text), click on "log to file".
A cool thing to do is when you're coding, log the terminal, and then when you cat the Xterm log, you see coding in fast forward. If you wanted you could video it.
Note that there are also other menus in xterm, accessible using Ctrl+Left Click, Ctrl+Middle Click, Ctrl+Right Click.
Log file will be in the directory that you launched Xterm from, and will be in the format: Xterm.log.<hostname>.<date>.<time>.log.
This is a very good question, there's no reason to mark down a question like this.
It can be done in two ways:
Using script:
xterm -e script mylogfile -c "someCommand -i input_file -o output_file -f someArg"
Redirect to a file:
xterm -e 'someCommand --arguments 2>&1> /path/to/mylogfile'
I do essentially this with "terminal-window", mrxvt, "hcm" and "pypty".
terminal-window wraps mrxvt, just filling in some commandline options. mrxvt is a lightweight, multitabbed, nonunicode terminal emulator not dissimilar to xterm.
hcm is a GUI that makes it easy to run a shell (or other command) on a remote host. It can also start an mrxvt with remote ssh's without requiring the GUI if you prefer (using hcm-term).
pypty is a /usr/bin/script reimplementation that is written in Python. It is not significantly different from /usr/bin/script, except it gives a "dated files mode", that allows you to have one file per pseudo terminal per day. So if you leave a shell logged in overnight, you get one file per day - this tends to make it easier to find what you're looking for.
All this combines to give you pseudo terminal logging with great ease. Commands are run on remote hosts, but logged locally. Just start a "fancy terminal-window" (or use hcm-term), and everything you see on the screen plus control characters (but not nonechoed passwords) will be logged under ~/.hcm/logs/<year>/<month>/<day>/* .
Also, if you hit the shell button in the lower right of mrxvt, you get another ssh session into the same remote host, which is also logged locally (to a different file under ~/.hcm/logs/...). When I started making use of that feature, I had no idea how much I would grow to like it.
You can obtain them from http://stromberg.dnsalias.org/~strombrg/hcm/ There's a video there that shows how easy it is to set up and get started with.
BTW, fancy terminal-window sets up $PS0 or "trap DEBUG" to give you command start times and finish times. It's great for post mortems. It does this without replacing any of the usual bash startup files.
I wrote terminal-window, hcm and pypty, but I can't take credit for mrxvt. :)
HTH

How do I copy everything from my terminal to a file including the stdout and the prompt using C?

I know how to get the stdout into a file using dup/dup2 system calls, but how do I get the entire output that would be normally shown on my terminal(including the prompt that says my username along with the $ symbol and the current working directory) to a file?
Yes you can, but this may be difficult in many details (depending on your expert level). For the shell to behave normally (I would mean exactly as in a terminal), then it needs to interact with a terminal (special system object). So you need to create a program that behave like a terminal, this what pseudo-terminals devices (/dev) are intended for. Read documentation about this to implement it but roughly, your application should behave like the user so should be connected to the slave side of the pseudo-terminal, and the shell to the master side of the pseudo-terminal. Then you can easily log real inputs made by the user and catch outputs made by the shell.
Can't comment cause of low reputation.
I would say there is no way to do that inside a code in C. Instead, you could use bash for example to redirect everything to a file, and leave the code in C as it is.
In this way you have all the info you want to save: prompt, current directory, call to the program (including flags), and of course the output of the program.
Well, you can do:
-For bash prompt PS1: Echo expanded PS1 (in case you want it expanded, if not there is a simple way to do it just echong PS1)
- For executed command: https://unix.stackexchange.com/questions/169259/how-to-capture-command-line-input-into-logfile-and-execute-it-at-the-same-time
- Standard output and error output: Redirect stderr and stdout in a Bash script
And that's all you want to capture, I think.
Look up the script command in Unix systems. If you want to capture all keyboard and std in/out for a command, use the script executable. If you want to see how it's done, look up the source.

Retrieve data from COM port using a batch file

I'm trying to automatically retrieve data from a COM port using a batch file.
I'm able to configure the com port and to send the command in other to ask my device for the info.
The problem is that I'm not able to capture the data that the device sends. I've tried with RealTerm and the device is working and sends the info back to the pc, but I really need the batch file to do it automatically, here is the code:
echo off
MODE COMxx ...
COPY retrievecommand.txt \\\\.\COMxx:
COPY \\\\.\COMxx: data.txt
Any suggestions?
Use the TYPE command in a recursive loop using the DOS GOTO command to a DOS LABEL. Use 'append output' to capture text like TYPE COM1:>>Data.txt The double > means continually concatenate (or append) to Data.txt. A single > or 'redirect output' would replace the text in Data.txt every loop (if com data present on port). Add a 2nd line that redirects to the monitor screen so you can watch activity too (i.e. TYPE COM1:>CON [CON means console or monitor screen but you can omit it as console is default anyway])
Control-Z is not needed by TYPE command. It will just dump text continually until operator does a Control-C and then a Y to break the loop. You really don't need to stop the loop unless you are done with the batch file all together. The Data.txt file will be available to other programs live and will not present a 'Sharing Violation' if you try to access it with another program like NOTEPAD.EXE while this batch file is still looping.
Also if you make a 3rd line in the batch file that says TYPE COM1:>Data1.txt [notice only one redirect], you will have a single line of instant text that will disappear with next iteration. But sometimes that is helpful if you need only one line of data. There are creative ways to extract one line of data to another text file using the DOS FIND command.
When reading, the COPY command will continue until it detects the end of file. As the source is a device (with a potentially infinite stream) it only knows to stop when it detects an end of file marker. This is the Ctrl-Z (0x1A) character.
The suggestion in the duplicate question of using the TYPE command to read is likely to result in the same problem.
There is no standard mechanism to read a single line. If you can port your application to PowerShell, you should be able to read single lines with the results you expect.

Additional console window

I have application that has to write to console. Also I call function from dll that writes to stdout too. Now I want to have separate output window to get all output from dll there. (So I will have 2 console windows: one for client app, one for dll) How to make it? I use windows+mingw
You can't. stdout is a single file handle and if both your application code and the dll are writing to it, they're going to go to the same place no matter what you do.
Your best options would be to either:
change your application code to write to something besides stdout (i.e stderr or a file), or
change your application code so that its output statements are 'tagged' in a way that you can filter using a tool like grep or sed/awk

Way to differentiate between cmd line args and drag-onto-icon args in Windows?

I have a Windows GUI app written in C (MinGW) and would like to have the app perform different tasks depending on whether it was launched via the command line with a filename argument or by dragging a file onto the application icon. The way it is now, the following function doesn't differentiate between the two:
int argc;
LPWSTR *argv = CommandLineToArgvW(GetCommandLineW(),&argc);
When a file is dragged onto the application's icon, it assumes it was launched via the command line. The problem with this is that I need additional arguments that must be passed via command line in order to do anything useful. The filename itself is not enough, so the app just quits because it doesn't have enough information to proceed.
What I would like is for the user to be able to drag a file onto the app icon, and have a window come up asking for the required options. If the user launches the app via command line with the required options already supplied, the app would immediately start processing without asking for additional input. Is this possible?
Another issue I am having is that sometimes when a file is dragged onto the app's icon, it crashes. I narrowed it down to anything operating on the argv[] values. It doesn't do this if launched via command line with the same argument. For example, this will crash the app about 20% of the time:
fprintf(stderr,"argv[3] was %ls\n",(LPWSTR)argv[3]);
Why would this only happen when launching via drag-n-drop? I am on Windows 7 x64.
Windows will by default call your program with the file name of the file you dropped on the its icon as the first and only argument. So you will get exactly the same invocation parameters in this case that you get when somebody starts your program from the command line with the full qualified name of the same file as the one and only argument.
You can however add additional arguments to a shortcut icon when you install your application i.e. "path\myapp.exe -gui". That allows you to differentiate between invocations via the icon in general (also applies to double clicking without any parameter) and invocations on the command line where the -gui parameter will usually not be specified.
It's certainly possible. Let's say the user must specify -slow or -fast on the command line. Your code then looks something like:
int main( int argc, char *argv[] ) {
if ( argv contains "-slow" or -"fast" ) {
we were launched fronm the command line
else
we were either launched from an icon, or the user has
not specified -slow or -fast. In either case, pop up
a dialog to get the options
endif
}
I don't think you can, when you drag a file over an icon, the OS executes the program using the file name as argument in the command line, so they are effectively the same.

Resources