@TJvV, thank you for the the additional information, which has indeed helped. There is now a new CLI release, 11.30.10, that introduces a -t
option to bypass the TTY autodetection that was introduced in 11.30.8. Could you try updating the CLI to version 11.30.10 and using the -t
option? The command line would be:
DEBUG=1 balena ssh da3cefd.local main -t
I expect it will make a difference because I noticed the following “substring” in your debug output:
... exec -i c725f7b...
I had expected that “substring” to be:
... exec -i -t c725f7b...
The CLI code that autodetects TTY is at: https://github.com/balena-io/balena-cli/blob/v11.30.10/lib/utils/device/ssh.ts#L106-L108
If you can, let me know whether using the -t
option indeed makes a difference, because I was not able to reproduce the error on Windows 10, macOS and Linux, including several Windows shells: Git Bash, MSYS2, WSL bash, Command Prompt and PowerShell. However, I was able to simulate the behaviour you described by modifying the TTY autodetection code to pretend that stdin is not a TTY.
If -t
“solves” the problem for you, the next step would be to try to understand the reason why TTY autodetection fails in your environment. It could be something specific to Windows 7, or it could be something else. I could revert the code to remove TTY autodetection and always force TTY allocation, but this is also problematic because it prevents executing remote commands by piping them to balena ssh
, for example with Git Bash:
echo "ls -la; exit;" | balena ssh da3cefd.local main
The above should execute "ls -la"
on the device/service and print the output on your development host, but it only works if stdin is auto detected as not being a TTY. Before CLI 11.30.8, the piped command execution was not working for ssh to service containers on local devices,* and 11.30.8 fixed it at least on Windows 10, macOS, Linux. Piped commands to the host OS (rather than to services) have worked for a long time, and the feature was mentioned in balena’s January newsletter:
Which is why we would have to think twice before dropping TTY autodetection altogether, if autodetection is confirmed to be the reason for the issue you described.
* Note (to save you the trouble of reporting it!): piped commands to service containers on remote devices (given the device UUID and service name, and going through the balenaCloud gateway) do not currently work because of an issue in the balenaCloud gateway. I have raised it internally to the backend team.
Thanks again for testing it and helping us fix it.