-
Notifications
You must be signed in to change notification settings - Fork 5.5k
file.replace turns CRLF line endings to CRCRLF #12284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'm unsure if this is a Python bug or if we're misusing |
I'm running off the develop branch, commit
|
Thanks for the update! |
I think we need to replace the fileinput usage. It has caused more than a |
Cross-ref #8051. |
@basepi, fileinput is out, and this behavior around CRLF line endings is no longer occurring. I think this issue can be closed. |
Awesome! |
Closing due to issue being resolved. Please ping me or open another issue if someone thinks this is incorrect. |
I've been having a look at how the file.* functions work under Windows, and I've found that file.replace, with args to replace 'charlie' to 'charlie2', turns -
File 1
... into
File 2
I've narrowed this down to what seems like a Python bug with the fileinput module, but I'm nowhere near certain. Below is the script I'm using to reproduce this behaviour, derived from the code used by Salt's file.replace with unimportant bits stripped out.
Running file 1 through this script, with the args 'charlie' to 'charlie2', results in file 2. If the
mode
argument tofileinput.input
in the script above isr
instead ofrb
then it works as expected.I think it is due to the file being opened in text mode for writing, while being open in binary mode for reading. Looking at the code for the fileinput module (Python built-in) it seems like when
inplace=True
, the output file is always opened in text mode. Is this a Python bug?The text was updated successfully, but these errors were encountered: