- This topic has 39 replies, 8 voices, and was last updated Oct 28-11:10 am by BobC.
-
Posts
-
BobC
zblsv, I don’t actually KNOW the language well enough to write much code. I have been programming almost 50 years, but this isn’t a language that I would say I “know”.
Given that I’m learning the language, I deconstruct what I am trying to do into small steps, and then search for the best example I can find of something similar to each small step on the web, and copy the code, changing the field names or details (for example the daynumber with echo), and testing with a time command from a terminal, each step additively, till I get the whole thing working properly, then copy and paste what worked into a script file in geany. I did generally understand the daynumber line, but not the exact syntax, so if what I found works, I go with it, unless time or my Pentium II say its too slow.
I don’t mind suggestions and pointers, as a matter of fact I appreciate them, as long as they are explained, if necessary.
In order to test incrementally, and have things still work when done, I try not to change it after I test it 🙂
My intent was to just have a one field command to track. I don’t think I want to try and track the exact commands with all their parameters to try to compare to the toolbar, personal menu, menu, and menu-applications, thus I tried to have one string to compare against. I substituted the space if an interpreter was used with ~~~ because I don’t think I will ever find ~~~ at the beginning of a command naturally.
tmpfile is created because if I don’t store the output of ps into a file, all the other programs used in the command string get added to the list of programs running. By putting the results in a file I only need to ignore the ps command.
I don’t understand the reasoning for the grep -x or regular expression comments.
Could you make the changes you think are best to correct my code and I will convert my current test data (if necessary) and test your method?
Current code:
#!/bin/bash # xappsrunninglogger - appends log of current days since epoch and running xwindows app names to logfile ~/xappsrunning.log every 60 seconds (60x per hour=1320x per day) while :; do daynumber=$(($(date --utc --date "$1" +%s)/86400)) ps -U $(whoami) -o args > ~/tempfile && sed 1d ~/tempfile | sed 's/^\/bin\/bash /\/bin\/bash~~~/g' | sed 's/^\/usr\/bin\/python3 /\/usr\/bin\/python3~~~/g' \ | awk '{print $1}' | sort | uniq | grep -v -x -f ~/xapps-ignore.lst | awk -v daynumber=$daynumber '{print $1, daynumber, 1}' >> ~/xappsrunning.log awk 'BEGIN { FS=OFS=SUBSEP=" "}{arr[$1,$2]+=$3 }END {for (i in arr) print i,arr}' ~/xappsrunning.log > ~/xappsrunningsummary.log sort < ~/xappsrunningsummary.log > ~/xappsrunning.log rm -f ~/xappsrunningsummary.log sleep 60 done- This reply was modified 1 year, 8 months ago by BobC.
zblsv
this isn’t a language that I would say I “know”.
I actually do not know people who could say otherwise.
tmpfile is created because if I don’t store the output of ps into a file, all the other programs used in the command string get added to the list of programs running.
ps, sleep, wc are all in xapps-ignore.lst already.
grep can be added.Could you make the changes you think are best to correct my code
I suggest completely different architecture.
Not xapps-ignore.lst but xapps-watch.lst: to define what will be monitored, not what will not.I don’t understand the reasoning for the grep -x or regular expression comments.
Another interpreters are ruby, perl, awk…
To support them, you must add two piece of code: ~~~ing and the lines in xapps-ignore.lst
Without ~~~ing you must only add the lines in xapps-ignore.lstWords are carried away by the wind...
zbslv,
“I suggest completely different architecture.
Not xapps-ignore.lst but xapps-watch.lst: to define what will be monitored, not what will not.”Ok, I agree that would be better, not as good as the launcher logging what was launched, but a good next choice. Ok, what does it take to make that work?
Use case example: I install another file manager or browser, or other app. Maybe I should add it to the toolbar immediately if it was added to the menu?
If I don’t add it immediately, it won’t be included in the list to watch for, and won’t be until the toolbar watch for list is refreshed, and won’t make it to the toolbar unless I run it more after its being watched for, and then won’t appear on the toolbar until after the next toolbar regeneration.
It seems now I need to modify the apt post install/menu generation, and personal menu maint, application menu maint, and watch for the toolbar itself being changed to know I need to refresh my watch for list.
I’m not saying these are impossible tasks, just that I don’t know how to do all that.
zblsv
I see it like that:
Distribution vendors in advance have added to watch list all apps they know about.
Now, if you compile and install something in the Home, it’s your responsibility to add it to the smart panel.
The smart panel can keep track of package installation: it simply will regularly check the list of installed packages.
It even can look for executable files in the Home too.
If it find something interesting, it will inform the user by some kind of welcome icon in order to add new apps on it.Words are carried away by the wind...
I agree that working from the apps, and only tracking those makes good sense, but don’t think anyone else would cooperate to make lists, etc.
I am thinking of saving the date last updated and checking the underlying menu and toolbar files to see it any are newer, and if they are, refresh the list to include anything not in my previous list. It wouldn’t take a lot of cpu time to check a few file mtimes, and that way as soon as an app is added to a menu, it gets tracked.
zblsv
don’t think anyone else would cooperate to make lists, etc.
Strictly speaking, it is developer’s task to maintain the lists.
It is not so obvious, for instance, that “firefox” in the menu will show “firefox-esr” in the ps output.
But, an app must be added only once for everyone, and the user community could share the lists.Words are carried away by the wind...
I thought about what it would take, lacking developer support to accomplish, and it’s pretty complex.
If an xapps-watch.lst was created, it would need to be maintained as well, and every time someone created something new to add to the menus or toolbar, it would need to be added to the list, so that when it was running it would be tracked, otherwise that app would mysteriously be missing (ie a bug in user perception).
To catch programs added from packages, a script to refresh the xapps-watch.lst could be created and added to the apt post install script list. This script would also need to run after any menu or toolbar maintentance was done. We could call it the xapps-watch-refresh
The program would need to recursively process the $HOME/.icewm/menu file and any menufiles called by them to make sure all of the program lines are on the xapps-watch.lst so we can search for their command strings.
That would be in addition to the script doing the tracking and another to analyze the tracking and recalculate what should go on the toolbar.
I’m not sure its worth all the effort.
I’m on vacation today 🙂
So I went after the problem from the source. Yes, its a lousy solution to change the IceWM code, especially since I don’t know the language, but I was able to get it almost working. I just need a little help from someone who knows C++ to get the command line arguments included in my log file so I can distinguish the different commands being run from the menu or toolbar. I was able to get it to work for options run with up to 1 parameter, but couldn’t figure out how to get it to output more than 1.
Sample output:
APPLAUNCHED 2021-10-26 21:52:06 /usr/bin/icewmbg (null) APPLAUNCHED 2021-10-26 21:52:06 /usr/bin/icewm --notify APPLAUNCHED 2021-10-26 21:52:06 /home/bobc/.icewm/startup APPLAUNCHED 2021-10-26 21:52:10 /usr/bin/mtpaint (null) APPLAUNCHED 2021-10-26 21:52:18 /usr/bin/x-terminal-emulator -e APPLAUNCHED 2021-10-26 21:52:34 /usr/games/gnome-nibbles (null)My problem is that it gets args as an input parameter, and I don’t know how to write it to my file. If I had the log of what was run, I’m pretty sure I could come up with the rest of the code needed…
Can anyone help?
The code is from yapp.cc (as identified by Xecure)
int YApplication::runProgram(const char *path, const char *const *args) { flushXEvents(); int cpid = -1; if (path && (cpid = fork()) == 0) { resetSignals(); sigemptyset(&signalMask); sigaddset(&signalMask, SIGHUP); sigprocmask(SIG_UNBLOCK, &signalMask, nullptr); /* perhaps the right thing to to: create ptys .. and show console window when an application attempts to use it (how do we detect input with no output?) */ setsid(); #if 0 close(0); if (open("/dev/null", O_RDONLY) != 0) _exit(1); #endif closeFiles(); // My code starts here // Get time formatted for applaunched log char albuff[20]; struct tm *alsTm; time_t now = time (0); alsTm = gmtime (&now); strftime (albuff, sizeof(albuff), "%Y-%m-%d %H:%M:%S", alsTm); // Open applaunched.txt to record events char fullfilename[PATH_MAX]; strcat(strcpy(fullfilename, getenv("HOME")), "/.icewm/applaunched.txt"); FILE* applfile = fopen(fullfilename, "a"); // Write (add) applaunched event to log, with args parameters if possible if (args) fprintf(applfile, "APPLAUNCHED %s %s %s\n", albuff, path, args[1]); // HOW DO I GET IT TO WRITE ALL OF THE PARAMETERS??? else fprintf(applfile, "APPLAUNCHED %s %s \n", albuff, path); fclose(applfile); // End of my mods if (args) execvp(path, const_cast<char **>(args)); else execlp(path, path, nullptr); fail(_("Failed to execute %s"), path); _exit(99); } return cpid; }- This reply was modified 1 year, 6 months ago by BobC.
Brian Masinick
https://www.geeksforgeeks.org/command-line-arguments-in-c-cpp/ might be a helpful resource. I’m pretty rusty too, been retired a few years and it’s been a couple of decades since I’ve actively coded in C or C++. But I at least remembered about argc and argv, so maybe this will help.
--
Brian MasinickBrian,
The call to runProgram is a bit different. As you can see it passes the full path and program name being called as the first argument, and the second is an array of null terminated strings, according to what I found, and since its a pointer, what worked was to chug through it until the value was a nullptr.
int YApplication::runProgram(const char *path, const char *const *args) {From stackoverflow: https://stackoverflow.com/questions/27541910/how-to-use-execvp/27542113
The first argument is the file you wish to execute, and the second argument is an array of null-terminated strings that represent the appropriate arguments to the file as specified in the man page. For example: char *cmd = "ls"; char *argv[3]; argv[0] = "ls"; argv[1] = "-la"; argv[2] = NULL; execvp(cmd, argv); //This will run "ls -la" as if it were a commandXecure did identify the right spot and came up with the while loop idea, but my lack of coding knowledge/skill pushed me into just guessing and trying many permutations of syntax until I found something that both compiled and worked (thus far, this is entirely experimental). I’m posting it in case someone might help improve it, not to suggest its well written. I would wish it would be optional by configuration parameter and the log filename be configurable, not hard coded, but I was happy to make it work at all.
fprintf(applfile, "APPLAUNCHEDA %s", albuff); int i = 0; while (args != nullptr) { fprintf(applfile, " %s", args); i++; if (i > 15) break; } fprintf(applfile, "\n");Example lines of output matching menu and toolbar program and arguments:
APPLAUNCHEDA 2021-10-28 04:29:46 mtpaint APPLAUNCHEDA 2021-10-28 04:29:53 x-terminal-emulator -e alsamixer APPLAUNCHEDA 2021-10-28 04:32:23 ~/bin/antixscreenshot.sh APPLAUNCHEDA 2021-10-28 04:33:19 desktop-defaults-run -t su-to-root -c /usr/local/bin/ddm-mx -i nvidiaThe spam filter is preventing me from entering the log or code so I will try attaching them.
- This reply was modified 1 year, 6 months ago by BobC.
- This reply was modified 1 year, 6 months ago by BobC.
- This reply was modified 1 year, 6 months ago by BobC.
- You must be logged in to reply to this topic.
