monotone

Issue 211: `mtn cat` output adds extra newlines on Windows when redirecting to a file

Reported by Richard Hopkins, Aug 19, 2012

Steps to reproduce the problem:
-------------------------------

1. Create a test file 'test.txt', UTF-8, Windows newlines (CRLF) 
with the numbers {1,2,3,4} each on a new line.
2. Add the file and commit it.
3. Execute mtn cat test.txt > test.txt
4. View test.txt again, there will be extra newlines in between each 
number.

Expected result:
----------------
The file should be exactly the same.

Actual results:
---------------
The file has extra newlines in between each number.

Output of `mtn version --full`:
-------------------------------
monotone 1.0 (base revision: unknown)
Running on          : Windows NT/2000/XP/2003 (5.1, build 2600, 
Service Pack 3) on ia32 (level 15, rev 19458)
C++ compiler        : GNU C++ version 4.5.2
C++ standard library: GNU libstdc++ version 20101216
Boost version       : 1_46_1
SQLite version      : 3.7.5 (compiled against 3.7.5)
Lua version         : Lua 5.1
PCRE version        : 8.12 2011-01-15 (compiled against 8.12)
Botan version       : 1.8.11 (compiled against 1.8.11)
Changes since base revision:
unknown

Comment 1 by Richard Hopkins, Sep 10, 2012

Add new test to check for garbled output from `mtn cat`

The original issue was found using Java to read from the monotone
process stdout on a Windows XP system, but was also reproduced
using `mtn cat FILENAME > FILENAME`. However, on Linux (only
tested on SUSE so far) no lines are garbled, even with newlines.

I think the culprit is 'dump_file' which uses '<<', and the
documentation states it performs formatting, where as 'put/write'
perform no formatting.

Whilst `mtn cat FILENAME > FILENAME` can be expressed as `mtn 
revert FILENAME`
which works correctly and does not garble new lines (even on 
Windows),
my opinion is that it should still work. The intention is to get the
full original version, and `mtn cat FILENAME` is quicker to type
and more efficient than using automate commands to fetch the 
workspace
manifest, then request the content given a file_id.

An example usage is using `mtn cat FILENAME` from a NetBeans IDE
integration plugin, as NetBeans only needs the full original text
of a file and automatically works out a diff, shows editor markers
in the margin etc when in an editor window. The current plugin
uses `mtn cat FILENAME` which works on Linux regardless of newlines
in files, but fails on Windows when the file has Windows newlines 
(CRLF).

Comment 2 by Stephen Leake, Sep 11, 2012

'mtn automate get_file_of FILENAME' is a direct replacement for 'mtn 
cat', and does not have the problem.

Comment 3 by Richard Hopkins, Sep 11, 2012

Well spotted, I missed that automate command but I will use that 
from the NetBeans plugin regardless.

Your patch on the mailing list looked like what I had though, so I 
don't know how to fix `mtn cat`.

Comment 4 by Richard Hopkins, Oct 30, 2012

There's another related issue.

When trying to merge-3 a file on Windows that contains Windows 
newlines (CRLF) and has a conflict, the files to compare and merge 
interactively have the same problem, so every other line is blank. I 
tested on Windows XP and diffuse 0.4.6.

As a workaround I copied 'temp_file' from 'std_hooks.lua' into my 
workspace 'monotonerc', but provided 'rb+' (binary mode) to the file 
open call. This fixes the file contents in diffuse, but then breaks 
the commit message when firing up notepad; notepad only handles 
CRLF.

As a workaround for the notepad issue during commit I downloaded 
Notepad2, added it to PATH, and set EDITOR to Notepad2.

Created: 5 years 3 months ago by Richard Hopkins

Updated: 5 years 19 days ago

Status: New

Followed by: 1 person

Labels:
Type:Incorrect Behavior
Priority:Medium

Quick Links:     www.monotone.ca    -     Downloads    -     Documentation    -     Wiki    -     Code Forge    -     Build Status