Skip to content
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

Append/prepend in file.replace assumes '\n' line endings #27368

Closed
lorengordon opened this issue Sep 24, 2015 · 10 comments
Closed

Append/prepend in file.replace assumes '\n' line endings #27368

lorengordon opened this issue Sep 24, 2015 · 10 comments
Labels
Bug broken, incorrect, or confusing behavior Execution-Module help-wanted Community help is needed to resolve this Needs-Testcase PR needs test cases written, or the issue is about a bug/feature that needs test cases P3 Priority 3 Platform Relates to OS, containers, platform-based utilities like FS, system based apps severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around stale Windows
Milestone

Comments

@lorengordon
Copy link
Contributor

I noticed this while investigating another issue around the append/prepend functionality. The code uses '\n', which is probably not appropriate on Windows. Should probably change that to os.linesep.

https://github.com/saltstack/salt/blob/2015.5/salt/modules/file.py#L1509

Could alternatively add a linesep parameter that defaults to os.linesep, so people can override if they choose?

@jfindlay jfindlay added Execution-Module Bug broken, incorrect, or confusing behavior severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around Windows P3 Priority 3 Platform Relates to OS, containers, platform-based utilities like FS, system based apps help-wanted Community help is needed to resolve this labels Sep 24, 2015
@jfindlay
Copy link
Contributor

@lorengordon, I think choosing the line ending from os.linesep is the right way to go. I don't think there is a need to override that with a function parameter, which would have to go into all file execution module functions (and states) that ultimately work with file line endings.

@jfindlay jfindlay added the Needs-Testcase PR needs test cases written, or the issue is about a bug/feature that needs test cases label Sep 24, 2015
@jfindlay jfindlay added this to the Approved milestone Sep 24, 2015
@lorengordon
Copy link
Contributor Author

@jfindlay Sometimes I work with Unix files with '\n' line endings on a Windows box. If there is no parameter to override a default line separator, it might be nice to attempt to autodetect the line ending. Perhaps just read the first line of the file? (Naive, but easy and probably good for most use cases...)

I think other execution module functions could easily add support for a line separator parameter over time, especially if the logic is separated into a private helper function. I was just referring to a parameter for file.replace. Am I missing something?

@jfindlay
Copy link
Contributor

@lorengordon, I think this could become a big, complex change with many unintended consequences. Autodetection may be a better solution in my opinion. I created #23740 and #24089 at the suggestion of @UtahDave to work around some of these issues and it seems to be working so far.

@lorengordon
Copy link
Contributor Author

@jfindlay, this is the other issue I was referring to, regarding line endings.

I understand why salt.utils.fopen was modified to require binary mode on windows, but re-reading the io.open() docs, I wonder if it would make sense to use that function instead of the default open(), and change the default back to text mode. io.open supports universal newlines, which is intended to provide cross-platform line-ending support on file handles, while allowing devs to write code assuming \n line endings. The io.open function also takes a newline parameter that can be used to override the default behavior, and that parameter could be exposed via salt.utils.fopen easily.

@jfindlay
Copy link
Contributor

@UtahDave, what is your opinion on this? It seems that io.open is python 2.6, 2.7 and 3 compatible.

@lorengordon
Copy link
Contributor Author

@jfindlay, found another issue bringing up a similar idea: #14135

@stale
Copy link

stale bot commented Jan 23, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

@stale stale bot added the stale label Jan 23, 2018
@lorengordon
Copy link
Contributor Author

Handling of line endings still needs a revamp.

@stale
Copy link

stale bot commented Jan 23, 2018

Thank you for updating this issue. It is no longer marked as stale.

@stale stale bot removed the stale label Jan 23, 2018
@stale
Copy link

stale bot commented May 8, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

@stale stale bot added the stale label May 8, 2019
@stale stale bot closed this as completed May 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior Execution-Module help-wanted Community help is needed to resolve this Needs-Testcase PR needs test cases written, or the issue is about a bug/feature that needs test cases P3 Priority 3 Platform Relates to OS, containers, platform-based utilities like FS, system based apps severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around stale Windows
Projects
None yet
Development

No branches or pull requests

2 participants