This makes the following changes:
- The `append_newline` argument to the `file.blockreplace`
remote-execution function has been modified so that if its value is
`None`, it only appends a newline when the content block does not end
in one.
- A couple of fixes were made to newline handling. The existing code
normalized the newlines in the content block, replacing them with
os.linesep. However, when the file contains newlines that don't match
the OS (i.e. POSIX newlines in a file on a Windows box, or Windows
newlines on a Linux/Mac/BSD/etc. box), then we would still end up with
mixed newlines. The line separator is now detected when we read in the
original file, and the detected line separator is used when writing
the content block. Additionally, the same newline mismatch was
possible when appending/prepending the content block. This has been
fixed by using a common function for appending, prepending, and
replacing the content block.
- Support for the `append_newline` argument has been added to the
`file.blockreplace` state. The default value for the state is `None`.
A `versionchanged` has been added to the remote execution function to
let users know that the Fluorine release will change the default value
of that variable.
- 20 new integration tests have been written to test the
`file.blockreplace` state.
If this is has any unicode characters in it, it won't load on systems that do
not default to a unicode locale.
find . -type f | while read line; do ret=$(file $line); if [[ $ret == *UTF-8* && $line == *.py ]]; then echo $line; fi; done
The above will list all files that have unicode characters in it and won't load
with locale set to C or POSIX
This further abstracts some of the setup and teardown code so it can be
used for git-over-http tests.
It also moves the code that was originally added to the archive
state integration tests to create a local http server into
salt.support.helpers so that it can be more easily and portably used.
