☰

bg 命令的奇怪行为

tag-icon • tag-icon linux debian process
bg 命令的奇怪行为

如果进程（应用程序）始终期望在终端上输入并始终将接收到的数据从 uart 发送到 stdout，如何将进程（应用程序）发送到后台？

我无法使用 CTRL+Z & bg %number / bg %% 将我的应用程序发送到后台。

任何想法，出了什么问题？

我的设备（程序）在发送到后台之前需要来自终端的一些输入命令进行配置。当我尝试将其发送到后台时出现错误。

# [CTRL-Z]
[1]+  Stopped                 sudo ./my_app

# bg %1

它向我显示如下内容：

[1]+  Stopped                 sudo ./my_app

答案1

当后台运行的程序尝试从终端读取数据时，由 SIGTTIN 信号停止。输入当前正在进入前台进程；如果输入随机进入前台程序或后台程序，则会造成破坏。所以后台程序会被挂起，直到它被放到前台为止。

如果您只需要在开始时将数据传递给程序，请将数据通过管道传输到其中。

echo "config=foo" | ./my_app &

如果您需要时不时地与程序交互，但它在大多数时间可以在无人值守的情况下继续执行，请在终端多路复用器中运行它，例如屏幕或者多路复用器。以屏幕为例：

screen -S my_app ./my_app

键入必要的输入，然后按Ctrl+A分离屏幕会话，即让它在后台运行并返回到原始终端。当您想再次与程序交互时，重新连接到屏幕会话：

screen -S my_app -rd

如果您需要自动执行一些复杂的交互，请编写一个预计脚本（或具有类似库的另一种语言的脚本）。

¹流程组，但我不打算在这里深入讨论这个微妙之处。

答案2

如果你的命令继续从 tty 读取，那么你需要调用

fg

在收到“已停止”消息以键入预期输入后。

答案3

难道你不应该将参数传递给标准输入，因为它继续工作吗？如果你只是 CTRL-Z 它，它将在后台等待输入。

例如

$ cat test.sh
#!/bin/bash

read var
echo $var

$ cat <<EOF > input
d
EOF

$ ./test.sh < input
d

$ ./test.sh <input > stdout 2> stderr &
[2] 23180
[2]-  Done                    ./test.sh < input > stdout 2> stderr

$ cat stdout
d

当尝试在不传递输入的情况下启动它时：

$ ./test.sh > stdout 2> stderr &
[2] 13012

[2]+  Stopped                 ./test.sh > stdout 2> stderr

相关内容