2

I've got some python code which is getting line endings all wrong:

command = 'svn cat -r {} "{}{}"'.format(svn_revision, svn_repo, svn_filename)
content = subprocess.Popen(command, shell=True, stdout=subprocess.PIPE).stdout.read()

written = False
for line in fileinput.input(out_filename, inplace=1):
        if line.startswith("INPUT_TAG") and not written:
            print content
            written = True
        print line,

This fetches a copy of the file called svn_filename, and inserts the content into another file called out_filename at the "INPUT_TAG" location in the file.

The problem is the line endings in out_filename. They're meant to be \r\n but the block I insert is \r\r\n.

Changing the print statement to:

print content,  # just removes the newlines after the content block

or

print content.replace('\r\r','\r')  # no change

has no effect. The extra carriage returns are inserted after the content leaves my code. It seems like something is deciding that because I'm on windows it should convert all \n to \r\n.

How can I get around this?

Daniel
  • 1,994
  • 15
  • 36

2 Answers2

0

CRLF = Carriage Return Line Feed.

Python on Windows makes a distinction between text and binary files; the end-of-line characters in text files are automatically altered slightly when data is read or written.

https://docs.python.org/2/tutorial/inputoutput.html#reading-and-writing-files

Can you output as binary file and not as a text file?

If you prefix the string with r to open the file as raw, does this prevent extra \r in the output?

Community
  • 1
  • 1
AaronS
  • 465
  • 1
  • 7
  • 10
  • for line in fileinput.input(filename, inplace=1, mode='rb'): bizarrely makes things worse. Not only are the \r\r\n still there but the rest of the file now has them as well (not just the inserted section) – Daniel Nov 23 '14 at 22:12
0

I can "solve" this problem by doing the following:

content = content.replace('\r\n', '\n')

converting the newlines to unix style so when the internal magic converts it again it ends up correct.

This can't be the right/best/pythonic way though....

Daniel
  • 1,994
  • 15
  • 36