Changes:EXIT xzm

[dreadbird]

I dont know if changes EXIT is a feature of nemesis.

my take on it you could have your "changes directory" in an .xzm. So my script would save-changes to the xzm.

then when you boot nemesis with graphics it loads all your changes without making changes to them. Then call save-changesnew (for nemesis when its made) and it will update your "changes directory" .xzm.

instead of having changes9.xzm in /porteus/modules it will be put in /changesExit9/changes9.xzm

after calling save-changes new it appends extramod=/changesExit9 to the graphic menu options. It will be a prompt and open a text file if its not already in the porteus.cfg. I can parse it and see if its already there. if not open text editor.

then once its set it will load your changes. This would allow for multiple changes directories ie /changesExit3 and /changesExit4

I as well could build in syncing the changes to an actual changes directory. /changes9. So you have the .xzm to load graphics with your changes that wont be changed unless you save. Or you can use it regularly in graphics changes with /changes9 as its synced with the /changesExit9/changes9.xzm.

This would be useful if you did something you didnt want on /change9 on changes mode. you would simply just go back to /changesExit9/changes9.xzm as it would revert the changes.

[Vic]

Hey dreadbird

This thread includes Nemesis stuff so maybe link to that sub-forum or start a dedicated thread there.

Thanks for your contributions to Porteus and Linux in general.

Vic

[Ed_P]

I noticed the Nemesis stuff also Vic and am thinking of moving the topic there.

[dreadbird]

Update

I have v2.0 done. just doing last minute tests and verifying results. Optimized scripts that is had to as it got a tad more in depth.
can be used it normally and with the SRC tag it will go to the highest folder count. IE the root and package that and you can customize the name.

Lets say you compiled something then from now until a definite peroid of time that has the highest directory count. that becomes the root and can be packaged to an xzm. So its another tool in the box. Anything that outputs to Source directory can be targeted.

Also recentchanges search the system file check outputs a tmpfile list. to check where apps get dumped in /tmp.



Change logs:
-added sha1sums to 1.11 as any new changes will be a new version
-When a search is made a directory is made to contain the old .xzm. Logic is introduced if no files are found the old files dont move. If there are files to grab the files are moved to a unique directory in /tmp.
-Batch starttime endtime and total time are scribed on the manifest for the .xzm. This is useful to quickly getting the total time of your files. You can then glance at the system log in that range for any missed files (maybe your filter excluded from /etc or someplace else).
-In a newer than file search logic is introduced in that the total time is relevant. feedback is then given appropriately as it differs with a system search. Example the difference file will be almost exactly the same as the search before. So the sensitivity has to be factored in. Adjust feedback and logic for newer than file search.
-Stability tweaks to ensure all scenarios are properly handled. refined and optimized statements. refined feedbacked in all scripts

02/24/2025

Implemented SRC tag. If you compiled an application it will go to the directory with the most occurences of a root directory. For example

Lets say these get past the filter and would consist of rntfiles.xzm

/home/guest/Downloads/myfile.txt
/var/cache/myfolder/myfile
/var/cache/myfolder/myfile2
/var/cache/myfolder/lib64/some.s0
/var/cache/myfolder/bin/application
/home/.mozzila/cache/somefile

The SRC tag returns in a custom named .xzm instead of rntfiles.xzm

/var/cache/myfolder/myfile
/var/cache/myfolder/myfile2
/var/cache/myfolder/lib64/some.s0
/var/cache/myfolder/bin/application

[dreadbird]

I have the version 2.0 complete. just tweaking it to possibly drag .tar files to /tmp in a folder ect. Ill explain how this works


rntfiles.xzm can package an application. as you can target any files made ie recentchanges 36 will grab all files and package it.

The SRC tag will take all new files and assume its localized. so lets say you definately have files in a directory somewhere. A compiled app or somewhere definate but maybe unknown.
It takes the power of rntfiles scope ie you are filtering items that get in the way. With SRC it will focus this on a single root directory. So taking it and using the full strength of the concept. If 1 or a dozen files get through the filter that dont belong with the app they are excluded automatically.

I implemented a customized name with selections, default name or you can enter a name of the .xzm!

Im delaying the release to implement:
Pacman tar files. SBO files in tmp. you can target those with SRC im currently implementing this. Localize grab them and move them to a folder in /tmp.

[Vic]

Hey dreadbird

Your posts make me feel like a cave man who was just unfrozen. Would it be possible at some point to boil everything down to simple explanations and maybe clarify the goal? I am so lost but I want to understand if I can benefit from your intense work. If not then that is cool.

Thanks for your efforts

Vic

[dreadbird]

Sure I was thinking of making a guide Ill make one as well. I added documentation to the -h or --help tag. It would be good to have a guide as well.

What I did was document everything so that it can be used to customize or even self maintain. I chose best practices no globbing, no fancy code, nothing outlandish. So it works on every machine. The idea was that it would help others to learn to use bash as well. Its a very powerful scripting language and thats because its simple.

If anyone has any problems with dates and foreign UTC times or something let me know and i can make it in different languages. Also if there are any bugs or wanted changed let me know and I can make the changes no problem

[dreadbird]

Happy friday new version of developer buddy - Updated: 03/07/2025

Save changes with developer buddy 2.0 Porteus 5.0 and 5.1
https://drive.google.com/file/d/1K7nQxq ... sp=sharing xzm

- The same as changescommit but with rsync
- An icon is in the application menu save changesnew for easier saving
- A log file is made in /home/$USER/Downloads of all changes saved
- Fully integrated with changes-exit.conf so to exclude any directories go to /etc/changes-exit.conf
- Includes developer buddy (recentchanges command)

developer buddy 2.0 NMS
https://drive.google.com/file/d/1VAgAQn ... sp=sharing xzm Nemesis

- Just developer buddy (recentchanges command)


Basic guide
https://docs.google.com/document/d/1EJA ... sp=sharing


Also if anyone has any tips about the code? or wants a new feature please let me know. I took careful consideration in feedback in the terminal and what is put in the log files. Anyways to improve I would gladly implement.

New changes

Fully integrated into changes-exit.conf. The save-changesnew command will read off of it.

Shotgun saving. when a new search or rntfiles.xzm is created with recentchanges the old searches are moved to a unique directory. If another search is made it creates a second directory for the old searches thus having 2 recent searches plus the new search in /tmp. Subsequently when a search is made the last recent folder is deleted.

A new feature is added recentchanges 60 SRC, recentchanges SRC 60, or recentchanges SRC. This command will isolate a root directory with the most files. So if any files get past the filter that shouldnt be they are excluded. It takes the power of the concept of recentchanges and implements it very well. If you output from a compiler to a root folder. recentchanges SRC would simply package it as an application.

This will show selections for filename, allow you to enter a filename or use a default filename through using an array. It will output a file _xdata that contains manifest and specifications.

How does this work? well based on the volume of files in a specific time they can be isolated and captured entirely. Not only does the filter make it easy to grab files but with SRC its even more powerful.

To achieve this the script bisects the logfile and can pinpoint the root folder. After compiling something to a directory try recentchanges SRC 60 and it will package it

recentchanges search the one that only does a system search in /Downloads. I have added a seperate file for the /tmp folder. So if you dont know where something outputs in /tmp. It will provide a convenient location to search all system files. I didnt put the /tmp files in the system search to make it less confusing. Its very clean only 3 files total will ever be made. The system search, a difference file and a systemTMP file. On subsequent searches it will remove old searches.

[dreadbird]

I took a break from developing as it does the job fairly well. The context of a root folder is a folder that has (usually) multiple folders. These would be /bin, /lib64, man, ect. So we have two ways to package an application.

Recentchanges 60 Lets say the compiled application took 48 seconds. So 60 seconds will capture all the files from the compiler. Your application will be packaged. But there is a catch. Lets say your application is in this directory structure.

/usr/local/myapp/bin/
/usr/local/myapp/lib64/

Other files that were modified within the 60 seconds
/etc/configfile
/home/guest/Downloads/myfile

You can see that because this file was modified during that time as well as a file was downloaded. No big deal as the application is included in the rntfiles.xzm.


Recentchanges SRC 60 Now this is the mode that focuses in on the root folder of the application. So for instance

/etc/ and /home/guest/Downloads/ will be excluded

So your application is targeted in /usr/local/myapp/ and now your application is packaged in an .xzm with a custom name or a selected name.


The thing is there is no way to define what a root folder could be. It may be of many different formats with multiple folders within folders. This is all well and fine but what happens if we have this example.


/usr/local/thisfolder/randomfolder/thisfile
/usr/local/thisfolder/myapp/bin/
/usr/local/thisfolder/myapp/lib64/
/usr/local/thisfolder/myapp/man/
/usr/local/thisfolder/myapp/man/man5/


you can see that with the appropriate algorithm it will select /usr/local/thisfolder/ thereby including /randomfolder/

So this is as close as you can get to capturing the root folder. But in 99% of cases /usr/local/thisfolder/randomfolder/thisfile will not happen. Thus the root folder will be found as /usr/local/thisfolder/myapp/.


How can we make it 100%? I could introduce root folder selection from an array. It will say select root folder: /usr/local/thisfolder/ or /usr/local/thisfolder/myapp/. Then you can say yes the second one is the application I compiled. So we can introduce this to make it 100%. But alas nothing is perfect so I could and probably will implement this. So we slowed the process down a lad. How can we counteract this?

The recentchanges command can have another alias rctchanges 60 for rntfiles.xzm or rctchanges SRC 60 for the custom .xzm. So thereby counteracting the added step of selecting the root folder and speeding up the usage of the command.


As a root folder can have many different variations there is no one step for all. But a number of screening filters can be put in place. For instance it could search for a /bin/ folder and drop the directory path by one and have the root. The program can detect this and not have to prompt for the root path. Or it could look for /man/ and drop by one again and the same effect. So these would be minor tweaks added behind the scenes to make it work seemlessly and being very effective.