Hi all
Just wondering if anyone has compiled a list of editors that can or can't save directly to the Retrode.
I've noticed for example that gedit can't but nano can. (under Ubuntu Lucid)
For now I'll maintain a list in the first post.
- Neelix
Command line solution
We have found this to work under any unixoid operating system. It may well be the most convenient way if you just want to change a single config setting:
echo "[HIDMode] 3" >> /path/to/RETRODE/RETRODE.CFG(Obviously, /path/to/ is the mounting point in your respective file system, e.g., /Volumes/ under Mac OS X. Replace "[HIDMode] 3" with any other config setting that you may want to modify (though there may be a maximum number of characters for which this works).)
List of editors (work in progress)
Editors that can save to the Retrode:
- Linux:
- kate, kwrite: need to disable backup of local files under Settings - Configure Kate|Editor - Open/Save - Advanced
- leafpad
- nano: may have to disable backups via echo "unset backup" >> ~/.nanorc
- notepad.exe via wine :-)
- Mac OS X:
- nano
- TextMate: file disappears from Finder after editing until Retrode is reset.
- TextWrangler
- vim: need to disable backups via echo "set nobackup\nset nowritebackup\nset noswapfile" >> ~/_vimrc
Editors that can't save directly to the Retrode:
- Linux:
- gedit
- vi
- emacs
- mousepad
- nedit
- Mac OS X:
Brilliant idea! We can try to gather some information here, than put up a list in the documentation section over on retrode.org.
On linux and OSX it'll suffice top drop to terminal and just do:
cp /Volumes/RETRODE/RETRODE.CFG ~/RETRODE.CFG
vi ~/RETRODE.CFG
cp ~/RETRODE.CFG /Volumes/RETRODE/RETRODE.CFG
Your paths may vary.
This also means you've always got a backup of your CFG handy for firmware updates.
UPDATE: looks like this doesn't work in Linux for some reason or another, tried it on my Ubuntu netbook this morning and couldn't get the config to write... it failed silently, though, so it was pretty frustrating. The same procedure repeated on a Mac worked fine, though. Weird!
Are you cleanly unmounting the retrode before you remove it? Many distros are set up by default to keep a cache of things to write to the disk, and don't actually write it for a while or until you unmount it.
That's a good point. I'll have to give it a punt. The short answer is: no.
The long answer is: no, because I'm lazy :)
Thanks for the protip, I'll try it tonight.
Quote from: gadgetoid on 31/Jan/2012 03:42:30 PM
On linux and OSX it'll suffice top drop to terminal and just do:
cp /Volumes/RETRODE/RETRODE.CFG ~/RETRODE.CFG
vi ~/RETRODE.CFG
cp ~/RETRODE.CFG /Volumes/RETRODE/RETRODE.CFG
Your paths may vary.
This also means you've always got a backup of your CFG handy for firmware updates.
UPDATE: looks like this doesn't work in Linux for some reason or another, tried it on my Ubuntu netbook this morning and couldn't get the config to write... it failed silently, though, so it was pretty frustrating. The same procedure repeated on a Mac worked fine, though. Weird!
While I can see the wisdom of keeping a backup, working around the issue really wasn't the point of the thread.
What would be more interesting to me in this context is whether vi can write the config file directly to the retrode or not. Have you actually tried that? (and if so, have you tried it on both systems?)
- Neelix
Fair point! I don't believe VI can successfully write directly to RETRODE.CFG, I have attempted it on both systems but not with any particular determination.
On my Mac, VIM (not VI, I've long since "alias vi = vim") gets: ""RETRODE.CFG" E514: write error (file system full?)"
Emacs also gets: "IO error writing /Volumes/RETRODE/RETRODE.CFG: No space left on device"
The free, GUI App TextWrangler, however, seems to manage a write under OSX. I wrote a test comment, and verified it by opening again in VIM.
So there's one for your list :D
Cheers! :-)
I've started a list in the first post. Not sure I'll keep it in the current format, might need to re-evaluate the format as i get more entries.
- Neelix
Thanks guys! I appreciate your taking care of this.
I think kate should support it - I haven't actually tested it though, so don't add it to the list. Because I believe kate moves the old file to RETRODE.CFG~ (and will report a warning if this fails), then writes the new file with the normal filename. But again, don't add it yet as I haven't actually tested it. I'll do so next time I'm at my desktop, if I remember!
Quote from: Muzer on 01/Feb/2012 10:10:53 PM
Because I believe kate moves the old file to RETRODE.CFG~ (and will report a warning if this fails)
If that's the case, the Retrode won't recognize it. The new file has to be written to the very same sector on the device. Whenever most programs rename a file, they only change the directory entry but the renamed file still points to the old storage location. Writing a new file, even with the original name, then redirects the new data to somewhere else.
Yes but what Muzer is saying is that it makes a backup copy but then writes the changes to the original, not the copy, in which case the copy would be lost but the RETRODE.CFG file would successfully be written. So theoretically, yes, it should work.
- Neelix
Tested it: kate complains a lot and doesn't save the file. As I predicted, it is the backup copy that causes the trouble (because it is not a deep copy but just a renamed link to the old data).
Told you so :)
In that case I'll add it to the list. Could you advise what platform you tested it on? As I see it, Its not guaranteed that the write method will be static across all ports of a program, so I want to keep a record of what's been tested on what platform.
- Neelix
Quote from: Matthias_H on 01/Feb/2012 10:49:12 PM
Quote from: Muzer on 01/Feb/2012 10:10:53 PM
Because I believe kate moves the old file to RETRODE.CFG~ (and will report a warning if this fails)
If that's the case, the Retrode won't recognize it. The new file has to be written to the very same sector on the device. Whenever most programs rename a file, they only change the directory entry but the renamed file still points to the old storage location. Writing a new file, even with the original name, then redirects the new data to somewhere else.
OH, I see - I thought the problem was with an inability to detect when things were renamed, rather than an inability to detect when things were saved with the correct name to a different block.
Would it in any way be possible to set aside a small "temporary storage" location in whatever memory is left over, that is cleared every time the retrode is plugged in; save any file written to the filesystem, regardless of the name, in that (obviously reporting disk full if it exceeds the available space), but constantly check the directory listing to see if any files are named RETRODE.CFG, and if so read them and replace the config? Or am I ridiculously overthinking things, and that would be really hard?
Quote from: Muzer on 01/Feb/2012 11:59:43 PM
Would it in any way be possible to set aside a small "temporary storage" location in whatever memory is left over, that is cleared every time the retrode is plugged in; save any file written to the filesystem, regardless of the name, in that (obviously reporting disk full if it exceeds the available space), but constantly check the directory listing to see if any files are named RETRODE.CFG, and if so read them and replace the config? Or am I ridiculously overthinking things, and that would be really hard?
On that note, Would it perhaps be possible to tune the virtual file system to let the OS think its writing to a new file, but direct it to the same memory space if the name matches?
- Neelix
@Muzer: Good idea but there's simply not enough memory for that. Mind you, the Retrode is already hallucinating a 128MB file system using only 3500 bytes of RAM. Right now, there are about 600 bytes left; not enough to even hold a single config file, let alone a whole chunk of SRAM data. The next major firmware revision will likely involve a desperate attempt at data compression, but I doubt it will free enough space to allow for such things.
@Neelix: Won't work because typically, first the data is written - then the file system entry (i.e., the name) is created. So we'd have to deal with the data before we even know what it's good for.
Actually, I just got kate and nano to work under SuSE 11.4. Both required deactivation of backups (instructions added to list)
Nano works already for me - must be the defaults in SuSE being rubbish. Never liked that distro ;)
I added nedit (failed) and leafpad (successful) to the list.
@Matthias: good call on the formatting :-)
- Neelix
Just found out that vim under Mac OS X does in fact work! Backups need to be disabled first:
echo "set nobackup" >> ~/_vimrc
echo "set nowritebackup" >> ~/_vimrc
echo "set noswapfile" >> ~/_vimrc
TextMate on Mac OS X can save the file but it disappears from Finder afterwards and you need to reset the Retrode to get it to reappear. But the change is saved.
Personally, I prefer to use pico from the command line.
Cheers! :)
I've added TextMate and pico to the list for Mac OS X.
- Neelix
pico is an ancestor of nano
So to clarify, are you actually using the earlier version pico, or are you using nano, and calling it pico out of force of habit?
(on my system, I can type nano or pico, and I get nano 2.2.2 either way. )
Keep in mind I'm not really familiar enough with MacOS X to know what versions of what tools are included.
- Neelix
Good point, I never realised.
I type pico and get nano (2.0.6)
What, no Windows editors?!
I've successfully saved the CFG file using Cream/vim in Win7.
http://cream.sourceforge.net/ (http://cream.sourceforge.net/)
Windows tends to be slightly less of a pain as far as media swapping and writing is concerned. I have no problems with Windows Notepad and Notepad++ (backup copies disabled) either, under XP Pro SP3.