PDA

View Full Version : [CLOSED] [2.0a1] (Minor) Mixed DOS and Unix line breaks



tjcrowder
6 Oct 2007, 7:37 AM
Hi folks,

Just a minor thing, it looks like several of the JavaScript files in the examples have a mix of DOS line breaks (CRLF) and Unix line breaks (just LF). It looks like a bunch of Unix-formatted files got a DOS-formatted standard header comment added to them, although some have a mix further on in the file as well. If your text editor (like mine) uses the first line to decide whether the file uses DOS or Unix line breaks so it can adjust accordingly, this makes it hard to read the files.

I didn't do a comprehensive survey, but here are the ones I noticed that had a mix:


ext-2.0-alpha1/examples/form/combos.js
ext-2.0-alpha1/examples/form/forum-search.js
ext-2.0-alpha1/examples/form/states.js
ext-2.0-alpha1/examples/form/xml-form.js
ext-2.0-alpha1/examples/forum/forum.js
ext-2.0-alpha1/examples/grid/paging.js
ext-2.0-alpha1/examples/locale/dutch-form.js
ext-2.0-alpha1/examples/locale/dutch-provinces.js
ext-2.0-alpha1/examples/locale/languages.js
ext-2.0-alpha1/examples/locale/multi-lang.js
ext-2.0-alpha1/examples/locale/PagingMemoryProxy.js
ext-2.0-alpha1/examples/menu/actions.js
ext-2.0-alpha1/examples/menu/menus.js
ext-2.0-alpha1/examples/tabs/tabs-adv.js--
T.J. Crowder
tj / crowdersoftware / com

mystix
6 Oct 2007, 8:47 AM
verified.

CR+LFs occur only in the license block


/*
* Ext JS Library 2.0 Alpha 1
* Copyright(c) 2006-2007, Ext JS, LLC.
* licensing@extjs.com
*
* http://extjs.com/license
*/

while LFs occur for the rest of the code.

Jul
7 Oct 2007, 3:43 AM
FYI: This problem exists with 1.1 as well. I reported this problem a long time ago: click me (http://extjs.com/forum/showthread.php?p=31824#post31824)

tjcrowder
7 Oct 2007, 4:14 AM
Thanks Jul.

Answering Jack's question (http://extjs.com/forum/showthread.php?p=31860#post31860) in that thread, I can easily normalize them to one or t'other with my text editor and send them in if it would help.
--
tj / crowdersoftware / com

mystix
7 Oct 2007, 5:17 AM
just curious, but in what way do mixed line endings cause problems? :-/

evant
7 Oct 2007, 5:50 AM
Not much, most editors will deal with them. For example when I open ext-all.css with visual studio, it prompts about the inconsistency and offers to clear them up.

tjcrowder
7 Oct 2007, 6:27 AM
From my original post:

If your text editor (like mine) uses the first line to decide whether the file uses DOS or Unix line breaks so it can adjust accordingly, this makes it hard to read the files.

It depends on the tool. My editor assumes if it sees DOS-style line breaks early on, that any LFs on their own later should be rendered as control chars, not line breaks. I can fix it, I'm just saying, probably best to be consistent...
--
T.J. Crowder
tj / crowdersoftware / com

rtannert2
7 Oct 2007, 8:41 AM
I have the same problem with BBEdit on the Mac. For many files in the distribution I have to globally replace \n with \r. It might be nice not to have to do it for every release, but I've dealt with it thus far.

Jul
7 Oct 2007, 11:27 AM
just curious, but in what way do mixed line endings cause problems? :-/

I guess you didn't follow the link I posted. For me, it causes a problem when trying to check the code into our local svn repository. I see this error:

Commit failed (details follow):
File '<insert any ext file here>' has inconsistent newlines
Inconsistent line ending style

jack.slocum
7 Oct 2007, 5:03 PM
I would imagine this is because we are all on different platforms. Any suggestions on how to deal with it?

mystix
7 Oct 2007, 7:05 PM
I guess you didn't follow the link I posted. For me, it causes a problem when trying to check the code into our local svn repository. I see this error:

Commit failed (details follow):
File '<insert any ext file here>' has inconsistent newlines
Inconsistent line ending style

sorry about that. missed the link you posted cos my screen brightness setting was on low.

trbs
7 Oct 2007, 7:41 PM
I would imagine this is because we are all on different platforms. Any suggestions on how to deal with it?

Setting a standard would help for one ;) one official way for line-endings that should honor when committing to the svn repository.

Besides that a script to check and cleanup/modify the line endings in the files which you could run once in a while just to be sure.

This could also (not sure if you would _want_ to do this automatically, but it's possible) be added to a svn-commit-post-hook to convert commits with mixed line endings when they hit the repository.

Maybe this script (for the unix/mac people) could be integrated in the Ext builder for Windows... so that you can click that and check/modify the code base before building. That would be the easiest for Windows people i think..

Anyways, just my $0.02

tjcrowder
8 Oct 2007, 1:33 AM
Meanwhile, if you have *nix, Mac OS, or Cygwin (http://www.cygwin.com/) (for Windows), you can convert all of the JavaScript files in your downloaded copy by switching to the base directory (e.g., ext-2.0-alpha1 or what-have-you) and issuing this command:


unix2dos -k `find . -name "*.js" -print`

or of course


dos2unix -k `find . -name "*.js" -print`


It's smart enough to only change the ones that need changing, so you don't get extra lines or extra CRs.

If you're using an old version of dos2unix (Cygwin's default version, for instance), it may not support -k (which preserves the timestamps of the files); just remove it.
--
T.J. Crowder
tj / crowdersoftware / com

JeffHowden
8 Oct 2007, 11:20 PM
I would imagine this is because we are all on different platforms. Any suggestions on how to deal with it?
As someone else suggested, standardize on something. Most editors (with an ounce of brains) on most platforms support choosing what [CR/]LF style to use.

tjcrowder
9 Oct 2007, 12:04 AM
@JeffHowden: Automagically, even. :)

tjcrowder
9 Oct 2007, 1:01 AM
The CSS files are also affected.

mystix
9 Oct 2007, 8:09 AM
For Windows users,

download the zipped attachment (DUUD.zip), unzip it to your Ext 1.1.1 / 2.0 root directory, and run dos2unix.bat / unix2dos.bat to your heart's desire.

dos2unix.exe / unix2dos.exe taken from http://www.bastet.com/.
batch files provided as is, by Yours Truly :))

enjoy ;)

trbs
10 Oct 2007, 10:56 AM
Let me just say that i standardize on Unix style line endings for the locale / translations javascript files.

Because they are a little bit smaller (1 character per line) then DOS style line endings.

So i would be +1 on standardizing and +1 for the standard being UNIX style.

jsakalos
10 Oct 2007, 11:57 AM
Me too.

mystix
10 Oct 2007, 7:03 PM
So i would be +1 on standardizing and +1 for the standard being UNIX style.

me 3 ;)

tjcrowder
10 Oct 2007, 11:13 PM
bandwagon.jump();

(E.g., me 4)

tjcrowder
18 Oct 2007, 2:45 AM
FWIW, this is still a problem in 2.0-beta1.

joeaudette
31 Oct 2007, 4:03 PM
Maybe a batch find and replace to make them consistent?

It is definitely a problem because if I try to add ext-2.0-beta to my svn repository for my open source cms project I get a zillion errors and have to keep trying after every error just to add the files.

Error: File 'C:\Users\JoeAudette\devprojects\mojoportal\joeaudette2\Web\ClientScript\ext-2.0-beta1\adapter\ext\ext-base.js' has inconsistent newlines
Error: Inconsistent line ending style

Really would like to see this cleaned up.

Also for all working on these files, when creating new files, please end each file with a new line as is the convention on *nix, windows doesn't care but it makes it much easier for use on *nix

mystix
31 Oct 2007, 7:10 PM
Maybe a batch find and replace to make them consistent?

It is definitely a problem because if I try to add ext-2.0-beta to my svn repository for my open source cms project I get a zillion errors and have to keep trying after every error just to add the files.

Error: File 'C:\Users\JoeAudette\devprojects\mojoportal\joeaudette2\Web\ClientScript\ext-2.0-beta1\adapter\ext\ext-base.js' has inconsistent newlines
Error: Inconsistent line ending style

Really would like to see this cleaned up.

Also for all working on these files, when creating new files, please end each file with a new line as is the convention on *nix, windows doesn't care but it makes it much easier for use on *nix

see post #17 above ;)

Jul
1 Nov 2007, 12:45 AM
bandwagon.jump();
(E.g., me 4)

Me 5. This is a real pain to deal with. It makes using Ext from SVN very difficult in our development environment.

jsakalos
2 Nov 2007, 4:34 AM
I have added this to the bug list; Jack assigns priorities though. ;)

Jul
3 Nov 2007, 3:40 PM
Thanks, Jozef. At least it's on the list now. :)

joeaudette
7 Nov 2007, 5:49 AM
I reiterate my vote that this is not a minor issue and needs to be fixed in the sources so that users don't have to mess with this.

I just killed an hour adding the files to me svn repo because every single file that has this problem causes an error. I should be able to just right click the top level folder and choose Tortoise SVN > add and it should buzz through and add all the files. Instead it errors a thousand times and I have to keep right clicking and TortoiseSVN -add a thousand times to get all the files added.

Its not a good out of the box experience and I've been through it now with 1.1, 2.0 beta, and 2.0 rc1.

Now that I know about the util for fixing it I will use that if needed but why can't someone on the team just do this to all the files once and for all and be done with it. I'm glad its on the list of to fix items now and hope it is fixed in rc2 or next release.

ExtJs seems a very polished project otherwise but this rough edge is a pain point that needs to be dealt with as a high priority in my opinion.

</endrant> :-)

Thanks,

Joe

mystix
7 Nov 2007, 5:55 AM
I reiterate my vote that this is not a minor issue and needs to be fixed in the sources so that users don't have to mess with this.

I just killed an hour adding the files to me svn repo because every single file that has this problem causes an error. I should be able to just right click the top level folder and choose Tortoise SVN > add and it should buzz through and add all the files. Instead it errors a thousand times and I have to keep right clicking and TortoiseSVN -add a thousand times to get all the files added.

Its not a good out of the box experience and I've been through it now with 1.1, 2.0 beta, and 2.0 rc1.

Now that I know about the util for fixing it I will use that if needed but why can't someone on the team just do this to all the files once and for all and be done with it. I'm glad its on the list of to fix items now and hope it is fixed in rc2 or next release.

ExtJs seems a very polished project otherwise but this rough edge is a pain point that needs to be dealt with as a high priority in my opinion.

</endrant> :-)

Thanks,

Joe

:-? i feel the pain in that rant...

but did you not try the tool i posted up there in post #17?

could've saved you that hour. ;)
until the issue's resolved, either that or the equivalent commands in linux should do the trick for us windows SVN users.

joeaudette
7 Nov 2007, 5:58 AM
I would have but just read about it now after the hour was gone. My original post didn't have me subscribed so didn't see your response to my previous post until after the hour ;-)

mystix
7 Nov 2007, 5:59 AM
I would have but just read about it now after the hour was gone. My original post didn't have me subscribed so didn't see your response to my previous post until after the hour ;-)

now you know ;)

joeaudette
7 Nov 2007, 6:07 AM
As an additional note, I'm not sure how the files got in this funky eol condition but I faced a similar issue in my open source project mojoPortal because most of our developers use VS 2005 on Windows but some use MonoDevelop on linux so early on when we started to encounter the eol issues in our files. Someone on our team researched it and found that if all the users configure their svn config files correctly line endings can be kept sane across platforms. I have notes about the configuration here:
http://www.mojoportal.com/tortoisesvn.aspx

The other thing we ask our windows devs to do is try to remember to always end any text based file with an empty new line as this is the convention for *nix and doesn't hurt anything on windows but makes things easier for linux users to view and edit the files.

Best,

Joe

mystix
7 Nov 2007, 6:29 AM
ooh.. useful tips. thanks!