我认为脚本看起来像:
script_one.shscript_two.sh
也就是说,脚本依赖于环境变量中的
.(当前路径)
PATH,这不是默认值。
因此,要使脚本正常工作,
.必须将其添加到
PATH某些启动脚本中。这种添加很有可能仅在交互式会话中发生(可能是无意间错误地)。可能是因为添加是在仅针对交互式会话执行(来源)的启动脚本中完成的。
JSch中的“
exec”通道(正确地)没有为会话分配伪终端(PTY)。因此,与使用SSH客户端登录时相比,(可能)获得了(可能)不同的启动脚本集。基于
TERM环境变量的存在/不存在,和/或在脚本中采用不同的分支。因此,环境可能不同于您与SSH客户端一起使用的交互式会话。
解决方案为(按优先顺序排列):
更正脚本,使其不依赖于
.
in的非默认设置PATH
。用显式路径调用子脚本:./script_one.sh
./script_two.sh
更正启动脚本添加
.
到PATH
无条件地(甚至非交互式会话)。(不建议)使用以下
.setPty
方法为“ exec”通道强制进行伪终端分配:Channel channel=session.openChannel("exec");
((ChannelExec)channel).setPty(true);
使用伪终端自动执行命令会给您带来讨厌的副作用。例如,请参见例如,有没有一种简单的方法来摆脱使用Python的Paramiko库进行SSH并从远程计算机的CLI提取输出时出现的垃圾值?
另请参阅相关问题使用JSch setCommand执行时,带有source选项的Shellping命令失败。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)