远程交互式执行带参数的本地bash脚本可行性问询

这个问题确实挺棘手的，我之前踩过类似的坑！其实是有办法同时满足交互式shell、执行本地脚本、传递参数这三个需求的，核心是要理顺远程shell的启动逻辑和参数传递的正确姿势，下面给你几个经过验证的可行方案：

方案一：通过标准输入传递脚本，执行后进入交互 #

用ssh -t强制分配伪终端（保证交互能力），同时让远程bash从stdin读取脚本内容，并用--分隔脚本参数，最后启动交互式shell：

cat local_script.sh | ssh -t your_user@remote_host 'bash -s -- arg1 arg2; exec bash -i'

细节说明： #

• bash -s -- arg1 arg2：-s让bash从标准输入读取脚本，--用来明确标记参数的开始，避免参数被误当成bash的选项；arg1 arg2就是你要传给脚本的参数，在脚本里可以用$1、$2获取。
• exec bash -i：脚本执行完成后，替换当前进程为交互式bash，这样你就能留在远程的交互环境里继续操作。
• 如果脚本本身需要交互（比如读取用户输入），-t已经为ssh分配了伪终端，所以能正常响应你的输入。

方案二：用Here Document在交互式shell中执行脚本 #

如果你的脚本依赖远程用户的交互式环境变量（比如.bashrc里定义的别名、路径），可以把脚本嵌入到远程交互式shell的启动命令中：

ssh -t your_user@remote_host 'bash -i <<EOF
$(cat local_script.sh) arg1 arg2
EOF'

避坑提示： #

如果脚本里包含$、`这类会被本地shell解析的特殊字符，一定要把Here Document的分隔符用单引号包裹，防止本地提前解析：

ssh -t your_user@remote_host 'bash -i <<\'EOF\'
$(cat local_script.sh) arg1 arg2
EOF'

方案三：先上传脚本到远程临时目录再执行 #

对于复杂脚本（比如包含大量特殊字符、依赖本地文件），先上传到远程临时目录是最稳妥的方式：

# 第一步：上传本地脚本到远程临时目录
scp local_script.sh your_user@remote_host:/tmp/

# 第二步：在交互式shell中执行脚本，完成后保留交互
ssh -t your_user@remote_host 'bash -i -c "/tmp/local_script.sh arg1 arg2; exec bash -i"'

可选优化： #

如果不想留下临时文件，可以在命令末尾加上删除操作：

ssh -t your_user@remote_host 'bash -i -c "/tmp/local_script.sh arg1 arg2; rm /tmp/local_script.sh; exec bash -i"'

为什么之前会出现冲突？ #

你遇到的问题本质是远程shell的两种模式冲突：

• 直接传脚本命令时，远程shell默认是非交互式的，没法支持交互操作；
• 强制启动bash -i交互式shell时，你传的参数会被当成shell的命令执行，而不是传给脚本。
  上面的方案都是先让远程shell在正确的上下文里执行带参脚本，再切换到交互模式，或者直接在交互shell的环境中执行脚本，完美解决了这个矛盾。

内容的提问来源于stack exchange，提问作者Jesse