"juju ssh" adds an additional strings to all commands when used on Windows, in interactive mode

[Adrian Vladu]

When used on Windows, juju ssh (interactive) adds additional strings to the ssh commands. As a consequence, every ssh command fails with command not found.

juju bootstrap still works, as the commands are given in a way that this bug does not affect them. Furthermore, if I add blank spaces before and after the command, the command partially works.

Example:
PS C:\Users\user> .\juju.exe ssh 0
Welcome to Ubuntu 14.04.2 LTS (GNU/Linux 3.13.0-55-generic x86_64)
 * Documentation: https://help.ubuntu.com/
  System information as of Thu Jun 25 12:07:06 UTC 2015
  System load: 0.06 Processes: 251
  Usage of /: 17.8% of 15.62GB Users logged in: 0
  Memory usage: 5% IP address for eth0: 192.168.1.101
  Swap usage: 0%
  Graph this data and manage this system at:
    https://landscape.canonical.com/

-bash: line 1: $'\r': command not found
-bash: line 41: $'\r': command not found <<<----- when I press Enter
ls
-bash: line 42: $'ls\r': command not found
  ls .. <<<---- when I add spaces after and before the "ls .." command
..:
ubuntu
: No such file or directory

Tested with juju-1.24, juju-1.25-alpha1 on Windows 8.1.

[Merlijn Sebrechts (merlijn-sebrechts)]

So, this is still happening and is clearly a dos vs unix line endings problem. This is a big problem for any dev using Windows... Any timeframe for a fix or a workaround?

[Anastasia (anastasia-macmood)]

PR against 2.1.x (develop): https://github.com/juju/juju/pull/6600

[Anastasia (anastasia-macmood)]

PR against 2.0.x: https://github.com/juju/juju/pull/6602

[John A Meinel (jameinel)]

The scope of the fix is such that it is non trivial to backport to 1.25. Given the number of people trying to run ssh onto Windows on 1.25 it doesn't feel worth the effort to develop a new fix there.

If we get significant demand that we really do need this, then we can reopen this, but its fairly accurate to say that we don't feel like this bug is worth the development effort at this time. 2.0/1 does have a fix for this, so it isn't an ongoing issue. And we're actively working on a migration path for 1.25 users to 2.X that is likely to be available in the 2.3 timeframe.