Editors that can save config files directly to the Retrode

[Neelix]

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:

Code Select Expand

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:
  
  
  • emacs

[Matthias_H]

Brilliant idea! We can try to gather some information here, than put up a list in the documentation section over on retrode.org.

[gadgetoid]

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!

[Muzer]

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.

[gadgetoid]

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.

[Neelix]

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

[gadgetoid]

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

[Neelix]

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

[Matthias_H]

Thanks guys! I appreciate your taking care of this.

[Muzer]

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!

[Matthias_H]

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.

[Neelix]

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

[Matthias_H]

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

[Neelix]

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

[Muzer]

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?