流打印和重定向

发布于 2024-12-01 00:13:59 字数 540 浏览 1 评论 0原文

我有一个程序,它(通过 printf)打印到 stdout 一些数据,并调用函数 *foo* 它还会向 stdout 打印一些数据 [从 foo 进行打印的方式(实现)未知,我看不到 foo 的代码]。

我必须将所有内容从 stdout 重定向到 buffer 或文件。我尝试通过多种方式来做到这一点

  1. freopen(file.txt, stdout) - 只有我的代码打印被写入 file.txt。从 foo 打印的内容丢失了。
  2. setbuf(buffer, stdout) - 只有我的代码打印被写入缓冲区。从 foo 打印的内容出现在标准输出中。(它出现在屏幕上)

什么可以解释这种行为?问题如何解决?

注意:此代码必须在跨操作系统(lunux/wind && mac OS)中工作。我使用 gcc 来编译代码,并且我有 cygwin

I have a program which prints (by printf) to the stdout some data and also calls to function *foo*
which also prints to the stdout some data [the way (implementation) of how printing is done from foo is unknown and I can`t see the code of foo].

I have to redirect everything from stdout to buffer or file. I tried to do it in several ways

  1. freopen(file.txt, stdout) - only my code prints are written to the file.txt. What was printed from foo is lost.
  2. setbuf(buffer, stdout) - only my code prints are written to the buffer. What was printed from foo is appears in the stdout.(It appears on the screen)

What can explain this behavior? How can the problem be solved?

Note:This code has to work in cross-OS( lunux/wind && mac OS).I use gcc in order compile the code and I have cygwin

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

血之狂魔 2024-12-08 00:13:59

很可能 foo 没有使用 stdio 进行打印并直接调用操作系统。

我不知道 win32,但在 POSIX 上你可以使用 dup2< /code>来处理它。

/* Before the function foo is called, make `STDOUT_FILENO` refer to `fd` */
int fd;
fd = open(...);
dup2(fd, STDOUT_FILENO);

编辑

令我惊讶的是,win32 有_dup2 但它还有其他作用。

It's likely that foo isn't using stdio for printing and directly calling the OS for this.

I don't know about win32, but on POSIX you could use dup2 to take care of it.

/* Before the function foo is called, make `STDOUT_FILENO` refer to `fd` */
int fd;
fd = open(...);
dup2(fd, STDOUT_FILENO);

EDIT

Much to my surprise, win32 has _dup2 but it does something else.

爱情眠于流年 2024-12-08 00:13:59

您如何知道 foo() 正在打印到 stdout?您是否尝试过将标准输出重定向到 shell 中的文件并查看 foo() 的输出是否仍然出现在屏幕上?

如果文件重定向将 foo() 的输出发送到文件,那么您可能必须重新调整文件描述符级别,如 cnicutar的回答。

如果文件重定向没有将 foo() 的输出发送到文件,则它可能正在写入 stderr 或者可能正在打开并使用 /dev /tty 或类似的东西。您可以通过与 stdout 分开重定向来测试 stderr

your_program >/tmp/stdout.me 2>/tmp/stderr.me

如果它打开 /dev/tty,输出仍会出现在您的屏幕上。

你在哪个平台?如果您可以跟踪系统调用(Linux 上的 strace,Solaris 上的 truss,...),那么您也许能够看到 foo( ) 函数正在执行。您可以通过在调用函数之前和之后编写一条消息来提供帮助,并确保刷新输出:

printf("About to call foo()\n");
fflush(0);
foo();
printf("Returned from foo()\n");
fflush(0);

printf/fflush 调用将在跟踪输出中可见,因此两者之间出现的内容是由 foo() 完成的代码>.

How do you know that foo() is printing to stdout? Have you tried redirecting standard output to a file at the shell and seeing whether the output from foo() still appears on the screen?

If the file redirection sends foo()'s output to the file, then you may have to rejig the file descriptor level, as in cnicutar's answer.

If the file redirection does not send foo()'s output to the file, then it may be writing to stderr or it may be opening and using /dev/tty or something similar. You can test for stderr by redirecting it separately from stdout:

your_program >/tmp/stdout.me 2>/tmp/stderr.me

If it is opening /dev/tty, the output will still appear on your screen.

Which platform are you on? If you can track system calls (strace on Linux, truss on Solaris, ...), then you may be able to see in that what the foo() function is doing. You can help things by writing a message before and after calling the function, and ensuring you flush the output:

printf("About to call foo()\n");
fflush(0);
foo();
printf("Returned from foo()\n");
fflush(0);

The printf/fflush calls will be visible in the trace output, so what appears between is done by foo().

‖放下 2024-12-08 00:13:59

什么可以解释这种行为?

当您调用的代码使用与您的代码不同的 C 库时,我见过这种行为。在 Windows 上,当一个 DLL 使用 GCC 编译而另一个使用 Visual C++ 编译时,我经常看到这种情况。这些的 stdio 实现明显不同,因此这可能会出现问题。

另一个原因是您调用的代码未使用stdio。如果您使用的是 Unix,您可以使用 dup2 来解决这个问题,例如。 dup2(my_file_descriptor, 1)。在许多实现中,如果您有一个 FILE*,您可以说 dup2(fileno(f), 1)。这可能不便于携带。

What can explain this behavior?

I have seen this sort of behavior when the code you are calling into uses a different C library than yours. On Windows I used to see this sort of thing when one DLL is compiled with GCC and another with Visual C++. The implementation of stdio for these is apparently different enough such that this can be problematic.

Another is that the code you are calling is not using stdio. If you are on Unix you can use dup2 to get around this, eg. dup2(my_file_descriptor, 1). On many implementations if you have a FILE* you can say dup2(fileno(f), 1). This may not be portable.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文