I am developing a script to make some changes via the uci command and then commit those changes.
But I am worried that if here are already unrelated uncommitted changes pending, that my 'uci commit' will inadvertently commit those pending changes as well as the ones I intend.
Is there a way to tell uci to store my uncommitted changes in a different directory, so they don't collide with any other pending uci changes?
I would have thought the -t option would do that, but -t appeared to make no difference.
I know I can "uci revert" at the beginning, but I'd rather have my own cache area.
Where else would the uncommitted changes come from except for you making those changes? Wouldn't you know about those changes?
Since you can issue the commits on a per-config file basis (i.e. network, firewall, dhcp, etc.), it would seem that you can avoid committing changes for the other files, and only commit the changes you are actively making anyway.
Here, if there are potential collisions, wouldn't it be important to know that at the time that you're making the changes? Imagine a situation where you make changes, commit them, and then some other commit undoes them or conflicts due to said collision. The commits should be one queue at a time... having multiple queues would be a recipe for disaster.
Wouldn't this make more sense? Or how about using uci changes to determine if there are any pending changes?
You could also approach it another way... your script that is writing the changes could also then use the uci changes at the end to verify that all of the requested changes are indeed pending, and that those are the only changes.
I don't see this option documented in the UCI user docs. Where did you see that as a valid option?
You're correct, it woud be me. But if the script I am talking about runs on cron, I could be in the middle of doing something interactively and the cron job hits and commits my incomplete changes. Probably a low probability, but I was looking to avoid the possibility.
Yes that would further reduce the probability.
I think this is the direction I should take.
From the built-in help of the tool. Typing "uci --help" in the shell includes the following:
-p <path> add a search path for config change files
-P <path> add a search path for config change files and use as default
-t <path> set save path for config change files
-q quiet mode (don't print error messages)
What would you be changing on a cron job? And how frequently is that cron firing? This could be bad for your system, and may be unnecessary. One of the few reasons to do this type of thing might be to change wifi credentials, but I can't really think of many other UCI elements that should be changed this way.
Meanwhile, maybe avoid making any changes to those files on the specific cron timings.
Better yet, make the script gracefully fail out if it detects any pending changes.
As I read this, it is the path for the actual final config file... not the UCI pre-commit staging. I think (although I could be wrong) that the UCI pre-commit staging happens in RAM. If you change the path of the final file, it won't work anyway (unless you then copy it into the right location, which still wouldn't solve your original concern).
I don't see any potential problems, but to be honest I don't see any benefits either. I'm just answering the question " Can uci store the cached changes somewhere else?".