C/C++ 程序如何将自己置于后台? [英] How can a C/C++ program put itself into background?

问题描述

对于从命令行启动的正在运行的 C 或 C++ 程序将自身置于后台的最佳方式是什么，相当于用户从 unix shell 启动时使用&"在命令的末尾?(但用户没有.)它是一个 GUI 应用程序，不需要任何 shell I/O，所以没有理由在启动后绑定 shell.但我希望在没有&"的情况下自动启动 shell 命令(或在 Windows 上).

What's the best way for a running C or C++ program that's been launched from the command line to put itself into the background, equivalent to if the user had launched from the unix shell with '&' at the end of the command? (But the user didn't.) It's a GUI app and doesn't need any shell I/O, so there's no reason to tie up the shell after launch. But I want a shell command launch to be auto-backgrounded without the '&' (or on Windows).

理想情况下，我想要一个可以在任何 Linux、OS X 和 Windows 上运行的解决方案.(或者我可以使用#ifdef 选择的单独解决方案.)可以假设这应该在执行开始时完成，而不是在中间的某个地方.

Ideally, I want a solution that would work on any of Linux, OS X, and Windows. (Or separate solutions that I can select with #ifdef.) It's ok to assume that this should be done right at the beginning of execution, as opposed to somewhere in the middle.

一种解决方案是让主程序成为启动真正二进制文件的脚本，小心地将其置于后台.但是需要这些耦合的 shell/二进制对似乎并不令人满意.

One solution is to have the main program be a script that launches the real binary, carefully putting it into the background. But it seems unsatisfying to need these coupled shell/binary pairs.

另一个解决方案是立即启动 另一个 执行版本(使用系统"或 CreateProcess)，使用相同的命令行参数，但将子进程置于后台，然后让父进程退出.但这与将自身置于后台的过程相比显得笨拙.

Another solution is to immediately launch another executed version (with 'system' or CreateProcess), with the same command line arguments, but putting the child in the background and then having the parent exit. But this seems clunky compared to the process putting itself into background.

在几个答案后编辑:是的，fork()(或 system()，或 Windows 上的 CreateProcess)是一种方法，我在最初的问题中暗示了这一点.但是所有这些解决方案都会创建一个后台的 SECOND 进程，然后终止原始进程.我想知道是否有办法将现有进程置于后台.一个区别是，如果应用程序是从记录其进程 id 的脚本启动的(可能是为了以后杀死或其他目的)，那么新分叉或创建的进程将具有不同的 id，因此任何启动脚本都无法控制，如果你明白我在说什么.

Edited after a few answers: Yes, a fork() (or system(), or CreateProcess on Windows) is one way to sort of do this, that I hinted at in my original question. But all of these solutions make a SECOND process that is backgrounded, and then terminate the original process. I was wondering if there was a way to put the EXISTING process into the background. One difference is that if the app was launched from a script that recorded its process id (perhaps for later killing or other purpose), the newly forked or created process will have a different id and so will not be controllable by any launching script, if you see what I'm getting at.

编辑#2:

fork() 对于 OS X 来说不是一个好的解决方案，其中fork"的手册页说如果使用某些框架或库是不安全的.我试过了，我的应用程序在运行时大声抱怨:进程已经分叉，你不能安全地使用这个 CoreFoundation 功能.你必须 exec()."

fork() isn't a good solution for OS X, where the man page for 'fork' says that it's unsafe if certain frameworks or libraries are being used. I tried it, and my app complains loudly at runtime: "The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec()."

我对 daemon() 很感兴趣，但是当我在 OS X 上尝试它时，它给出了相同的错误消息，所以我认为它只是 fork() 的一个精美包装器，并且具有相同的限制.

I was intrigued by daemon(), but when I tried it on OS X, it gave the same error message, so I assume that it's just a fancy wrapper for fork() and has the same restrictions.

请原谅 OS X 中心主义，它恰好是我眼前的系统.但我确实在寻找所有三个平台的解决方案.

Excuse the OS X centrism, it just happens to be the system in front of me at the moment. But I am indeed looking for a solution to all three platforms.

推荐答案

我的建议:不要这样做，至少在 Linux/UNIX 下不要.

My advice: don't do this, at least not under Linux/UNIX.

Linux/UNIX 下的 GUI 程序传统上不自动后台运行.虽然这有时会让新手感到厌烦，但它有很多优点:

GUI programs under Linux/UNIX traditionally do not auto-background themselves. While this may occasionally be annoying to newbies, it has a number of advantages:

• 在核心转储/其他需要调试的问题时轻松捕获标准错误.

• Makes it easy to capture standard error in case of core dumps / other problems that need debugging.

使 shell 脚本可以轻松地运行程序并等待它完成.

Makes it easy for a shell script to run the program and wait until it's completed.

使 shell 脚本可以轻松地在后台运行程序并获取其进程 ID:

Makes it easy for a shell script to run the program in the background and get its process id:

gui-program &
pid=$!
# do something with $pid later, such as check if the program is still running

如果您的程序自行分叉，此行为将中断.

If your program forks itself, this behavior will break.

Scriptability"在许多意想不到的情况下都很有用，即使是 GUI 程序，我也不愿意明确地打破这些行为.

"Scriptability" is useful in so many unexpected circumstances, even with GUI programs, that I would hesitate to explicitly break these behaviors.

Windows 是另一回事.AFAIK，Windows 程序自动在后台运行——即使是从命令 shell 调用——除非它们明确请求访问命令窗口.

Windows is another story. AFAIK, Windows programs automatically run in the background--even when invoked from a command shell--unless they explicitly request access to the command window.

这篇关于C/C++ 程序如何将自己置于后台?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！