File transfer to targets does not cater for line ending differences between Windows and Linux

[golflimaechoecho]

The current mechanism used by Bolt to transfer files does not cater for line ending differences between Windows (CRLF) and *nix (LF)

eg: when running Bolt on Windows host to a Linux target, task file line endings need to be fixed/modified manually to allow script files to run on Linux (eg: if Windows host used to run Bolt has files with CRLF endings, the script will not run on Linux)

Expected Behavior

• Bolt should cater for line ending differences between Windows and Linux (eg: tasks, scripts transferred to targets)
• Binary files / files that should not have line endings modified should still copy/transfer correctly

Steps to Reproduce

1. Create a task on Windows host with default CRLF line endings (or checkout project with GitHub on windows host with core.autocrlf set to true
2. Attempt to run task on Linux host - fails due to line endings

Environment

• Bolt 3.29.0
• Mainly affects Bolt running from Windows host to Linux targets (as Windows seems to cope/handle LF endings but not vice-versa)

[donoghuc]

Bolt intentionally does not interfere with line endings. If you are seeing a condition in which bolt is actually meddling with those please report it. If I am reading this correctly though it seems like you are requesting the opposite?

[golflimaechoecho]

Agree that Bolt currently does not interfere/modify line endings; while this may be intended (and completely valid) behaviour, could it at least be documented more obviously as it does impact/limit what can be done when running bolt on Windows to Linux targets (without additional/manual file munging by user and/or modules that need to be aware of this behaviour/limitation)