Modify SVN downloaded script

Is there way to return the script to what the format that author wrote it in? I find that I want to edit scripts, but when I use the SVN to download them, it takes out all line breaks. I don't have the will, nor the want to sit there, and clean up a 5000 line script, which has been condensed into 100.

I'd like to answer you, but I'm not sure I understand what happened to you.

Are you saying that when you download a script with svn it doesn't have line breaks? Or are you saying that editing a script that was previously downloaded with svn removes the line breaks?

If the former, then I can't imagine how that happened. If the later then you need a different editing program. I recommend notepad++.

As for returning the script to its original format... I think the real concern is to keep it from getting messed up in the first place.

In Ye Olden Tymes people who failed to configure Subversion properly for a multi-operating system environment would often have end of line problems when a file was committed from one OS and checked out into another. Deja vu?

The first thing to do would be to change text editors and see whether the desired formatting appears with a different editor. For example in plain vanilla Windows, NotePad renders what it reads but WordPad will convert the EOLs properly. If so then that is at least one workaround.

It is possibly that the embedded SVN in KoLmafia needs something tweaked, but it is also possible that the author's SVN client was not configured when the author checked in.

Or more simply, if the OS version between the scripter and the user doesn't match, then native text editors will display it in a way that just doesn't work. But, as you said, that's just a case where the user needs to change away from a naive text editor.

If mafia can't run the script, then that would be a case where mafia's SVN might need to change. Otherwise, it's simply people being lazy and needing to stop using Notepad.

There's also a third line-ending format, that was used on old Mac systems.
Windows: CR LF, Unix-like: LF, Old Mac: CR.

That means: files created by native windows editors will break lines almost correctly on the other two (they will just display (or hide) spurious weird characters at the end/beginning of each line).
Files created on the other two will not play well with windows, and likely with each other either.

Now, modern-ish editors should have autodetection, but that typically doesn't work if the file doesn't have end-of-line marker at the end of the file.
(having an EOL marker at EOF looks like having an empty line at the end of the file)

Specifically, version-revisioning systems are supposed to convert EOLs so that each checked-out work copies have canonical EOLs for their system (and server has server's EOLs), and that can break if there's no EOL at EOF. Or if there's any line with a wrong EOL, sometimes.

Huh... so you're saying that I really wasn't supposed to use the hex editor function to remove that EOL back when I was doing C coding?

Theraze said:

Huh... so you're saying that I really wasn't supposed to use the hex editor function to remove that EOL back when I was doing C coding?

Click to expand...

That reminds me of when I (recently!) used my text editor to edit a string in a binary (filling in the gaps with \0s), since a URL had changed, and my package manager hadn't updated to the upstream version that fixed the issue.

Theraze said:

Huh... so you're saying that I really wasn't supposed to use the hex editor function to remove that EOL back when I was doing C coding?

Click to expand...

That's something you shouldn't need to do. I think CVS had eol conversion already.
How to set up your editors (and everything else) so that it Just Works (tm) ... that's a different question.

(note: patch files will still have EOLs from the system that made them; so will any files you send by email or by uploading somewhere that isn't a VCS)

Was on a *nix server (BSD?) that failed to compile when using Windows EOL. Used PSCP to transfer files on/off, I just needed to fix EOL - the question was just whether, when manually changing EOL using hex, the final EOL should be removed or not.

Oh, no VCS then.

I would convert all CRLF to LF, and leave a final LF (empty line) at EOF.
Although I am lazy, so I would try to do it in VIM if possible (assuming it would detect windows EOLs correctly, converting to unix would be just :w ++ff=unix).
Next I would remember that some systems have dos2unix or dostounix commands (although I don't see one on mine).
And then there's sed -e 's/\r//g'

This reminds me of that one system that didn't even have ls (or enough memory to run it). If I wanted to see what's in the current directory, I had to echo *