所以我有一个bash脚本，它在同一个shell中运行得很好。如果我在命令行上运行这一行，我会得到tmp目录中列出的文件。我以root身份运行所有这些命令。
"kubectl -it exec -c mysql mysql-0 -- bash -c "ls -lah /tmp"当我像这样调用bash脚本时，它可以工作：
(works) ./z_mysql-init-pv_TEST.sh这里的问题是在另一个shell中运行一个与号：
(FAILS) ./z_mysql-init-pv_TEST.sh &权限设置为：-rwxrwxr-x
更新：我认为这里的问题不是bash问题，而是KUBECTL调用。正如@Chris Dood解释的那样，可能是Kubectl试图以某种方式从终端读取一些东西。其他所有东西都工作得很好（get，curl，log...）。我不知道，但我会继续探索。
最新消息：我只见树木不见森林！@SiHa谢谢你指出我面前的东西。我被“这应该能行！”的说法蒙蔽了双眼，我不相信这是我的问题。
1条答案
按热度按时间mm5n2pyu1#
给出的两个命令都将在一个新的shell中运行脚本，区别在于该shell是在前台还是后台运行
&，子shell将在前台运行，并将成为终端的控制进程（并可以正常与之交互）。父shell将等待子shell完成后再继续。&，子shell将在一个新的进程组中创建，父shell将保留对终端的控制（并且将立即提示而不等待子shell）。因此，重要的区别在于哪个进程正在控制终端的进程（组）以及如果/当孩子试图访问终端时会发生什么。除了终端的控制前台进程组之外的进程组中的任何进程都是“后台”进程，并且如果它访问终端则受到限制。
如果一个后台子进程试图从终端读取，它将得到一个SIGTTIN并被挂起。请注意，对于非阻塞读取，这将发生 even。如果一个后台子进程试图写入终端，会发生什么取决于终端的
tostop设置。通常情况下，这将是关闭的，但是如果它是开的并且孩子试图写入终端，它将得到SIGTTOU信号并且被挂起。所以你的命令失败的原因取决于它试图做什么的细节和你的终端设置。你可以通过运行
stty来看到后者--如果这个选项是开的，它会打印出tostop（以及其他东西）。如果问题是
kubectl或其他命令试图从终端读取，那么使其工作的唯一方法是给予它一些不这样做的选项（也许从/dev/null重定向其输入），或者在前台运行它。