The problem will be line endings. Windows uses CRLF and Linux uses just LF, so the CR will be seen as an extra unexpected (probably invalid) character, potentially invalidating the whole command line.
This shows up particularly in Telnet, where sending commands to a Unix/Linux system (eg the Humax) from a Windows Telnet client produces mostly OK command functions except there is a double command prompt in response (the CR is interpreted as a command ending, and then so is the LF). It goes wrong when a program requires user input, and then the CR screws things up. Usually there is a way to adjust the line ends in a Windows Telnet client: the Windows client itself requires the "unset crlf" command each time, or PuTTY has a configuration option.
When creating/editing files in Windows that are destined for a Unix/Linux system, it is important to use a programmer's editor with line ending options instead of just a normal Windows ASCII editor (eg Notepad) or word processor saving to .txt. It is however possible to covert a file from CRLF to LF, there are plenty of downloadable utilities to do that.