tmux + ssh + fish breaks. $SHELL gets evaluated locally / escaping problems?
What did you expect to happen?
Executing my upgrades for other machines works, unless I start using them inside tmux.
Having them as a dry-run exposes (for example):
/usr/bin/ssh -t flexo env TOPGRADE_PREFIX=flexo $SHELL -lc topgrade
What actually happened? The remote side gives back an error:
env: ‘/usr/local/bin/fish’: No such file or directory
But of course that cannot be executed like that: Although locally there is a /usr/local/bin/fish - no such thing exists remotely. The remote shell would be /usr/bin/fish (and is set as a default anyway).
So I guess $SHELL shouldn't be evaluated locally - so if I escape it manually (on the commandline) to be...
/usr/bin/ssh -t flexo env TOPGRADE_PREFIX=flexo '$SHELL' -lc topgrade
(pay attention to the single quotes around $SHELL)
... it works.
Now another error occurs if we have the yes flag activated, as it tries to run, but fails being unable to parse the commandline correctly. Weird.
Again, if I escape the given commandline to:
(Before)
/usr/bin/ssh -t flexo env TOPGRADE_PREFIX=flexo $SHELL -lc topgrade -y
(After)
/usr/bin/ssh -t flexo env TOPGRADE_PREFIX=flexo '$SHELL' -lc topgrade\ -y
it works.
Additional details:
Which operating system or Linux distribution are you using? macOS, from here trying to connect to multiple Linux hosts of different flavors. They all behave the same. How did you install Topgrade? * Manually downloaded and placed in /usr/local/bin (linux) or ~/bin/topgrade (macos) * Installting via Homebrew * Manually compiling
Run topgrade --dry-run to see which commands Topgrade is running. If the command seems wrong and you know why pleaes tell us so. If the command seems fine try to run it yourself and tell us if you got a different result from Topgrade.
Additional information:
Adding a '-v' to tmux for debbuging purposes outputs the called commands for tmux:
==> tmux-client-22626.log <==
1618514975.156154 sending message 106 to peer 0x7fc150008000 (0 bytes)
1618514975.156174 cmd_pack_argv: argv[0]=new-window
1618514975.156181 cmd_pack_argv: argv[1]=-a
1618514975.156188 cmd_pack_argv: argv[2]=-t
1618514975.156194 cmd_pack_argv: argv[3]=topgrade:1
1618514975.156201 cmd_pack_argv: argv[4]=ssh -t flexo env TOPGRADE_PREFIX=flexo $SHELL -lc topgrade --keep
1618514975.156216 sending message 200 to peer 0x7fc150008000 (98 bytes)
1618514975.156225 client loop enter
1618514975.166874 peer 0x7fc150008000 message 203
1618514975.166907 client loop exit
Even activating assume_yes without activating tmux generates an error - but it does not do so if I use -y.
I would assume the problem lies in using fish as the default shell for my machines It used to work in a quite old version (This broke around 2021)
Can I close this issue?
Looks like it's not fixed yet.
So I'm looking at this again — I actually started running it with remote_topgrades set in my config, from a macOS host to a Linux remote — and my biggest point of confusion is that I'm not actually sure what the Tmux feature is supposed to do here. It seems like cargo run -- --only remotes --tmux first launches another tmux window to run topgrade in and then that window launches another session to run ssh ... topgrade in.
What do you think this feature should do?
Maybe it should launch each remote in a new window in the current tmux session.
Fixed now in the dev branch?
Closed by #165
Sorry to reopen this issue - the very same problem remains for the very same setup