I have never executed a script, Python or otherwise, in Terminal.
After some fun discovery, I found the Python Launcher and the rest is history. I dropped the .ini and the .tmp files in a directory alone, ran the .py and bingo, I got the .bak and the .old, with the .ini now being just as we are accustomed to. Really appreciate your doing this, especially on my pestering you.
Thank you!
Want to be a huge help?
Write up a how-to for Windows.
Do you have Python installed? I can get it to work in a pretty non-portable way.
Write a .bat file in the directory with the two files:
@echo
[path to your python installation python.exe] unlock_presets_ini.py presets.ini presets.tmp
Tell me if that works. I refuse to learn the new Windows script stuff. But I will make an effort if the old BAT doesn’t works.
May be you can solve it in the OS? We don’t have a local time, but we have the FAT timestamp. What if you took the existing Modified Timestamp of the .ini and .tmp files after you mod them, and simply keep if they are in the correct order or add enough to the newer so it’s newer (say, other’s +1)?
Getting the directory path this way will allow the script to be run from anywhere without needing to cd
def main():
script_dir = os.path.dirname(os.path.abspath(__file__))
ini_filename = os.path.join(script_dir, "presets.ini")
tmp_filename = os.path.join(script_dir, "presets.tmp")
ini = ProffieSafe(ini_filename)
tmp = ProffieSafe(tmp_filename)
best = ini
if tmp.valid:
if not ini.valid or tmp.iteration > ini.iteration:
best = tmp
data = best.read()
ini.close()
tmp.close()
os.rename(ini_filename, os.path.join(script_dir, "presets.bak"));
os.rename(tmp_filename, os.path.join(script_dir, "presets.old"));
open(os.path.join(script_dir, "presets.ini"), "wb").write(data)
I’d be happy to do so for MacOS, but I do not have Windows. Let me know if needed. I’d be excited to contribute!
That’s sort of unfortunate though.
It uses the location of the script instead of the current directory, which is not very natural on most unix-like platforms. If I was using this script frequently, I would stick the script in $HOME/bin/ or /usr/local/bin/ then run it in whatever directory I want.
On windows, when you just click on the script, is the “current directory” set to:
a) where the script is
b) where the python binary is
c) something else?
First of all, I made an update to the script so that you can unlock any config file, not just presets.ini/tmp.
Second, I tested it on windows, and it seems like you can keep the script anywhere, and just drag-and-drop the config file you want to unlock onto the script. Of course, I did have to install python first, but I didn’t have to do anything else.
Oh, MacOS is simply dragging the script into Terminal and hitting return.
That just puts the path of the script in the terminal, doesn’t it? How about dragging the script first, then the ini file and then hitting return, does that work?
Sorry guys - possible 7.x OLED gremlin found…
Setup is three internal pixel accents wired in series and coded as sub blades to blink/pulse blue when main blade is off. In the video below, the accents in question are the ones inside the vents at the back of the speaker (two pixels) and the crystal chamber (one pixel). You can also see the OLED on the underside of the chassis reflecting off the tabletop.
The symptoms are that when the OLED battery level display switches off after about 30 seconds, the sub blade accents inexplicably light up full on - two white and one blue.
The problem doesn’t occur under USB power, only battery power.
Once the fault has started, if I power up the blade they return to normal, but again the problem returns around 30 seconds after I power the main blade down again, roughly coinciding with OLED battery level display turning off.
Config is set so all accents shutdown after half an hour.
The sub blade array is fed from data 1 so no need for a resistor.
The fixes I’ve found are:
So on the face of it, it looks like something about the OLED setup is upsetting data 1 under OS-7.x. Of course I’m happy to be corrected if it turns out to be a gremlin of my own making, but the fixes I’ve found above make me think that it isn’t.
Anyway here’s my config:
And here’s a video of the symptoms:
I only see the path of the script in the Terminal when I do that, as @profezzorn alluded to. If I push enter, I get a permission denied error in Terminal.
If there’s an easier way than installing the Python Launcher w/ Python 3, please let me know. The process I followed wasn’t difficult or prolonged at all, however.
If you’re in the directory with the script,
chmod +x ./unlock_presets_ini.py
to make it executable.
Yes. It puts the path of the script in, and enter runs it.
This is with the script in the same directory as the .ini and .tmp files.
For my testing, that directory is /Users/bconner/Desktop/py
Appending the .ini file to the command doesn’t work:
Traceback (most recent call last):
File "/Users/bconner/Desktop/py/unlock_presets_ini.py", line 82, in <module>
main()
File "/Users/bconner/Desktop/py/unlock_presets_ini.py", line 67, in main
ini = ProffieSafe(ini_filename)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/bconner/Desktop/py/unlock_presets_ini.py", line 9, in __init__
self.f = open(filename, "rb")
^^^^^^^^^^^^^^^^^^^^
NotADirectoryError: [Errno 20] Not a directory: '/Users/bconner/Desktop/py/presets.ini/presets.ini'
Do you have the latest version of the script?
No sorry, checking updates.
Latest version, MacOS Terminal.
Now dropping the script and enter doesn’t work. Need to drop script then ini file.
Confirming the previous symptom is fixed.
Subsequent clash events after blade turned off NOT triggering next TrDoEffect in a long TrConcat full of timed effect triggers.
So, we could use the FAT timestamp + 1, but we can’t update the fat timestamp. Writing to the directory is what caused sd corruption in the first place, and the reason for the new format.
Really silly solution (please don’t hit me): what about a third file called something like “lastest.ini” which just plains states the latest config. I.e. it will just have “presets.ini” or “presets.tmp”. It’s a lot easier to make a script that simply cats the name of the file you want to edit/backup/etc.
Not impossible, but it’s a single point of failure.
If you fail halfway through writing to that file, then you don’t know which file is the latest, and you need another way to decide which file is the latest, meaning that you’re essentially back to square one.