I thought this was an RCS problem (RCSProblemsOnWindows), but I am not convinced now. The symptom is that when I put the following:

1
2
3
4
5
-- Main.MartinCleaver - 21 Feb 2001 

On editing the page for the second time, this turns to:

1

2

3

4

5

-- Main.MartinCleaver - 21 Feb 2001 

And the problem gets worse on subsequent edits. .

• TWiki version: Dec 2000
• Web server: Apache
• Server OS: Windows NT4 SP6

-- MartinCleaver - 21 Feb 2001

I think it might be related to KfmBrowserSupportForEditing

Answer

Okay! Fixed it! It is related to KfmBrowserSupportForEditing On Windows you don't want the extra LF on resubstitution. I haven't worked out why, it might be something to do with whether Binary mode has been specified on the handle that reads in the file. Anyhow this fudges away the problem - alter bin/save[.pl].

90c90,91
<     $text =~ s/
/\r\n/go;
---
> #    $text =~ s/
/\r\n/go; # removed \r\n MRJC for   TWiki.Support.WhyDoLinesComeOutDoubleSpaced
>     $text =~ s/
/\n/go;

-- MartinCleaver - 25 Feb 2001

Hmm. I think the files might have been marked as text or binary or something. Certain old files in my web continue to exhibit this behaviour, but none of the new files do!

-- MartinCleaver - 24 Feb 2001

This topic is copied over from the Support web. Bug needs to be investigated.

-- PeterThoeny - 24 Feb 2001

September 2001 Release: changes has to be made at TWiki.pm file line 1512 (decodeSpecialChars) - I've just removed \r at % N % line.
(Keywords: new line, extra line)

-- LarsGregori - 24 Sep 2001

The bug exists in multiple places. Although Lars' fix seems to work for regular editing, the same problem exists when you Attach a file.

Here are some more details of the bug.

My Environment:

• Windows NT 4.0
• Cygwin (the latest) installed fully from internet yesterday.
• Perl 5.6.1 build for cygwin-multi (came with cygwin)
• Apache 1.3.20 win32
• rcs 5.7 (downloaded today from purdue.edu)
• rcs 5.7 patch for cygwin ( see http://sources.redhat.com/ml/cygwin/2000-08/msg00618.html )
• Twiki 01-Sep-2001

Here is a snippet of the text file "Test\WebHome.txt" freshly unzipped from the Twiki distribution:

   * TestTopic1, TestTopic2, TestTopic3, TestTopic4 {carriage return}{newline}
   * TestTopic5, TestTopic6, TestTopic7, TestTopic8{carriage return}{newline}
{carriage return}{newline}

Here is the same snippet copied out of the edit combo box:

   * TestTopic1, TestTopic2, TestTopic3, TestTopic4 {newline}
   * TestTopic5, TestTopic6, TestTopic7, TestTopic8{newline}
{newline}

Here is the snippet of "Test\WebHome.txt" after previewing and saving (no "changes" were made):

   * TestTopic1, TestTopic2, TestTopic3, TestTopic4 {carriage return}
{carriage return}{newline}
   * TestTopic5, TestTopic6, TestTopic7, TestTopic8{carriage return}
{carriage return}{newline}
{carriage return}
{carriage return}{newline}

Finally, here is the snippet copied out of the edit combo box again:

   * TestTopic1, TestTopic2, TestTopic3, TestTopic4 {newline}
{newline}
   * TestTopic5, TestTopic6, TestTopic7, TestTopic8{newline}
{newline}
{newline}
{newline}

It appears that somewhere during the "Preview/Save" process, instead of replacing the /n characters in the combo box with /r/n (as they originally were in the text file), /n is being replaced with /r/r/n. Then, the edit process seems to replace /r/r/n with /n/n.

After applying Lars' fix, the bug seems to go away for regular topic editing. However, it appears again during attachment uploads. After refreshing the "Test\WebHome.txt" file from source it, of course, contains the following:

   * TestTopic1, TestTopic2, TestTopic3, TestTopic4 {carriage return}{newline}
   * TestTopic5, TestTopic6, TestTopic7, TestTopic8{carriage return}{newline}
{carriage return}{newline}

After clicking "Upload File" and uploading a file attachment to the topic, "Test\WebHome.txt" contains the following:

   * TestTopic1, TestTopic2, TestTopic3, TestTopic4 {carriage return}
{carriage return}{newline}
   * TestTopic5, TestTopic6, TestTopic7, TestTopic8{carriage return}
{carriage return}{newline}
{carriage return}
{carriage return}{newline}

Same problem. Help!

-- DougKnesek - 23 Oct 2001

This might have to do with crlf substitution done by the Cygwin dlls.

Possible strategies:

• Make sure that TWiki always opens the files in binary mode. (The Perl pragma use open may help with this.)
• Mount everything within the Cygwin tree. The Cygwin docs say that no crlf conversion will be attempted for subdirectories mounted there, in particular if you use the -b option.
  I.e. use mount -b --change-cygdrive-prefix "/cygdrive" and tell Apache to serve from the DOS path (i.e. C:/Program Files/Apache Group/Apache/htdocs resp. C:/cygwin/local/usr/Apache/htdocs).
• Have TWiki explicitly strip all carriage returns before saving a text file to disk.

-- JoachimDurchholz - Updated 19 Oct 2001

The mount -b route seems to have worked for me, thanks.

Q: When running the Cygwin Setup.exe one of the questions it asks is whether the default text file type is DOS or Unix (I chose DOS on install.) Is that just a user friendly way of asking whether to use the -b option for mount? Or are there other changes as well?

Yes, it is a user-friendly way of asking whether to mount -b by default. [Main.JoachimDurchholz - 27 Oct 2001]

-- MattWilkie - 25 Oct 2001

I got this behavior in unix, with opera (opera linux 5.x). I guess they have some windows-way of handling \r\n that messes thing up.

-- ColasNahaboo - 26 Oct 2001

This is definitely not a Windows way. The only way this can happen is by misinterpreting \r as \n, which is nonsense regardless of what is being interpreted, or for what purpose.

-- JoachimDurchholz - 27 Oct 2001

The opera problem is probably OperaBrowserDoublesEndOfLines However I find that the fix mentioned (that is in the Sept01 release) doesn't seem to always work.

All the code for this is at line 1489 of TWiki.pm in encodeSpecialChars and decodeSpecialChars. Since the only time a \r (carriage return) should appear is right before a \n (newline) wouldn't it make sense to add handle these characters like this:

 encodeSpecialChars
    ...ignore other stuff not using \r and \n
    $text =~ s/\r//go;       # ignore all carriage returns
    $text =~ s/\n/
/go;

Note that some files in the TWiki distribution already come with \r\n line endings in them.
This means the above substitution should be done both when reading and writing files.

I agree that \r should be removed always.
It used to be abused for overprinting on mechanical printers in ye olde Unix days, and terminal drivers sometimes emulate this behaviour; but TWiki is neither a printer nor a terminal, so \r serves no useful purpose here.

- JoachimDurchholz - 18 Nov 2001

I agree, we should normalize properly the \r and \n. Please see my proposal (19 Nov 2001) on OperaBrowserDoublesEndOfLines

I submitted this bug to opera. I even made a small script to test this on http://koala.ilog.fr/cgi-bin/doublelinesbug

-- ColasNahaboo - 19 Nov 2001

This is in TWikiAlphaRelease and a duplicate of OperaBrowserDoublesEndOfLines.

-- PeterThoeny - 23 Nov 2001

Also see AttachedImageMangled

-- MattWilkie - 23 Nov 2001