I have noticed that some .Net code committed by a new contracting team has strange line endings. When I do a hex dump of the files I see that each line ends with 2 carriage returns (0d) and 1 line feed (0a).
When viewed in Visual Studio it looks like every code line has an empty line after it, which looks very odd.
What can cause this? It it some strange IDE? Could it be caused by Perforce? (I got the code out by syncing a Perforce workspace).
The only time I've ever seen non-standard line endings before is when people copy/paste code from a web page, email, or chat window. Could that be the cause?
If they submitted Windows-style (CRLF) line endings but used the unix (LF) LineEnd setting in their client workspaces, then the files would have an extra CR as part of each line, and a Windows machine would sync them down as CRCRLF. That's the most likely explanation for what you're seeing.
The ideal way to fix this is just for everyone to use a LineEnd that matches their environment (usually the default of local works just fine for this), but if someone needs to use a mix of tools/platforms within a single workspace, switching to the share LineEnd option will force everything to be normalized on submit by stripping all the CRs. (This also makes it impossible to submit text files with actual CR characters, but that's usually not a big deal -- for files where you don't want any sort of transformation to occur, use the binary filetype.)
Related
New to Oracle...
I have a bunch of SQL scripts from SQL Server that I want to edit into Oracle. I load these notepad-capable ASCII text files (ex: myscript.sql) into SQL Developer. When I open it, SQL Developer adds an extra line break between every line I had in the ascii text file. Annoying, but I can deal with that. I soldier on. I edit and change syntax. I run it. It works. I save. I'm happy so far. Feeling good.
But...
Now when I try to open myscript.sql in Notepad, line breaks are gone... there is a blank between every character in a word... it's a mess.
What the heck happened? And how do I make it stop? I know I'm old school, but I like to edit the format of my scripts myself... I want them in ascii text so that I can use a bulk file editor to change things...
I have googled this for a couple hours and have found countless pages regarding saving the OUTPUT of a script as text, but nothing about saving a SQL Developer script as plain text.
Welcome to the world of UNIX vs Windows/DOS line ending differences.
I would recommend using a better editor than Notepad. A modern code editing program will automatically handle the conversion and display.
http://www.cs.toronto.edu/~krueger/csc209h/tut/line-endings.html
So I still don't know how a couple of my scripts got so mangled up, because I can't recreate the issue. Other scripts are editing and saving just fine.
But I did figure out how to fix the couple scripts that did get hosed up.
I loaded Notepad++ for Windows. I opened the offending script, which shows a bunch of [NUL] all over the place. I was able to use the Searce/Replace function in 'extended mode' to search for \x00 (aka null) and replace it with nothing.
Next was the annoyance with line breaks (new line) versus "carriage return plus new line". I was able to use extended search and replace to replace \n with \r\n .
This now got me a file that I could edit in 'regular' notepad. I still don't know where the extra line breaks came into play, but I was able to spin through the file and remove the extra blank lines.
So all is well with the universe again. I got my couple of mangled scripts back in order, and others seem to behave properly now.
Thanks to all for the help. This site has been invaluable to me.
I'm on a Windows machine, and in my P4V workspace:advanced-settings, I have the following selected:
But I still notice extra spaces in some of my files after submitting and checking on a different machine. Is there a way to force every checkout and submission to be Unix style?
Note, I can't modify server settings, only my local workspaces.
If you set the LineEnd to unix and the files you sync have \r characters in them, it means that somebody using unix submitted them in that form (i.e. the files were checked in with the understanding that the Unix version of them is supposed to have those characters in there distinct from the native line endings). If you submit Windows-style files from a unix-mode workspace, you're saying that all unix workspaces should have Windows-style line endings for those files. This is desirable in some instances, like when you're using Unix machines to build packages for Windows systems, but for source code that's meant to be used cross-platform it's generally a bad thing.
It's not too hard to go through the history, figure out who did that, and cluebat them (or get the admin to force a fix of their LineEnd setting so that it actually matches the contents of their workspace), and I wholeheartedly recommend doing this any time you ask for unix files and get a win-style file that you didn't want. Usually if everyone uses the default setting of local everything works fine.
As far as fixing the files, a pretty easy method is to change your LineEnd to share, open all the files for edit, and then submit them -- the share setting forces all the \r characters to be stripped out on submit, as if you were running dos2unix over all your files every time you submitted.
I am working on Windows 7 and have a node.js project which is under git. I set up my TortoiseGit to autocrlf: false and safecrlf: false. Then changed all project files' line endings to LF. The project starts and operates normally and I see no reason to go back to CRLF.
Should I expect any side effects after doing this?
No, there is no problem at all using *nix end of line sequences on Windows (LF instead of CRLF). In fact, my personal recommendation would be to ensure your Windows editor (if you're developing node.js on Windows) to use LF.
Just as an example, I use Visual Studio Code for my editor developing node.js, and I have specified the following in my user settings to use LF instead of CRLF: "files.eol": "\n". Now I no longer need to worry about that.
CRLF line endings cause breaking issues in a node.js application that is run on Linux, and it isn't the most straightforward thing to troubleshoot if you don't know what to look for.
TL;DR Use LF while developing node.js applications on Windows if you really care about cross-platform (which you should care).
Note: just because git changes your line endings doesn't mean that is the solution. Even if you are ok with your version control changing your source code (which I don't recommend), if you do an npm publish it'll be using your source files locally and you could sneak CRLFs into the npm registry.
If all tools/editors/IDEs are LF compatible, then there is no problem.
Otherwiese you might get errors or mixed line endings on saving.
In order to make sure no conversion is happening for other users who clone your repository you can put a .gitattributes file into the root folder containing: * -crlf which disables all crlf conversions.
I have a delphi prog that reads from thousands of .txt script files that I have created over some years. I had to do some mass changes so used a search and replace program which in itself took a good few hours! The problem is now the top line of all the txt files seems to be messed up somehow - to me it looks fine however the delphi program doesn't read it and TortoiseSVN records it as a changed line!!
What on earth has happened and how might I resolve it? So far I'm having to delete all the files and remake them. Deleting the line and rewriting doesn't work - even Crtl+A and pasting the old file contents doesn't work! Its as if the header is corrupt?
Could it be a problem with end lines? (windows/UNIX/Mac are different eg \n or \n\r ) use an editor able to show special characters. I think you can with tortoise diff, switching the right option. Else, try with notepad++, for example
I had a project on Mac and uploaded it to a perforce server. When I got the project from PC all the line endings were changed and now it does not compile on PC. Is there a way to automatically change the line endings like they were before or I must submit again all the project from Windows? Is there any way to make perforce to keep my files AS THEY ARE? I really don't want to have stupid modifications in my source files.
Thanks!
EDIT:
It has to do with perforce, I just edited 10-20 files on MAC to make a multiplatform project to compile. The rest of 140k files were not changed and not even opened on Mac(they were opened by compiler to compile them:P). If I copy the project on PC the line endings are ok.
Line endings for text files are controlled by your client spec setting. You need to make sure that your client's 'LineEnd' value is set properly. In general, this should be left to 'local' which should do the right thing for whatever operating system you are using.
That said, depending on how this value was set on your Mac when you originally uploaded the files, I suppose that there could possibly be some problem when syncing those files to your PC.
I would check to make sure that LineEnd is set to 'local' for your clients. There is a note on the Perforce Knowledge Base site here that talks more in depth about proper settings for Macintosh clients. That might be a place to start as well to make sure that you have things properly configured on your Macintosh.
Yes you can. Using Unix line-endings for both your clients will tell the perforce clients to leave the files unchanged from how they were submitted. You can also setup a trigger on the server to force it this way, refer to my answer to this question:
Setting Perforce line endings
This doesn't have anything to do with perforce really, although it does handle the problem.
http://kb.perforce.com/article/63
Line endings on UNIX, PC and Mac machines are all different. This is what your seeing. Transferring the same file between PC and Mac over any medium would have the same results. You can probably set your editor on the Mac to save the file with windows line endings if you want to get around this another way.
I was wrong "Perforce processes all text files using Unix-style LF line-endings". I'd check p4 client LineEnd value (should be local on both machines I think) and ensure you're using a version of p4 >= 2001.1