3 ms·
Interesting. I do something similar like this: cat $script | ssh $server bash Haven't found a case where this fails yet (but I'm sure it's out there). Ed
by fooblat 5y ago
Interesting. I do something similar like this:
cat $script | ssh $server bash
Haven't found a case where this fails yet (but I'm sure it's out there).
Edit to add this also works nicely:
ssh $server bash < $script
Edit to add that I experimented a little and this is a simple way to run remote one liners via ssh:
ssh $server bash <<< 'cd /tmp; pwd'
- tyingq 5y agoI don't see an obvious situation where that would fail. People pipe tar output, rsync, dd, etc, through ssh without issue. Stdin doesn't seem to have quoting issues, which is what you would expect. The base64 in the parent post seems unneeded if you're passing through stdin/stdout.
- jlokier 5y agoIt fails when $script is something that needs to read data from standard input. I find that happens rather often with remote commands, so much that other quoting approaches are useful to have available
- Izkata 5y agossh has "-n" which I think stops that. It's worked for me most of the time when I end up with that or a similar situation (the once or twice it didn't IIRC involved experiments with chaining ssh commands).
- jlokier 5y agoNo, "-n" has the opposite effect to the one desired. "-n" is for when you have a server-side command that reads standard input and you want to prevent it from reading from the client side. "-n" cuts off the standard input so the server-side command reads empty input (/dev/null). The desired effect is when you want the server-side script to read input from the client environment. For example so you can give answers to questions, or interact with a terminal program. That's broken by piping $script in as input, and it's also broken by "-n".