PCLOSE(3P)
β¨ PCLOSE(3P) β¨
okay so bestie, welcome to the POSIX Programmer's Manual page for pclose π
this one is short, sweet, and honestly kinda iconic once you get it.
πΈ PROLOG πΈ
Real talk first, no cap: this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (so like, go check the corresponding Linux manual page for the deets on Linux behavior), or the interface may not be implemented on Linux at all. π Just keeping it honest with you.
π NAME π
pclose β close a pipe stream to or from a process π«Ά
π SYNOPSIS π
#include <stdio.h>
int pclose(FILE *stream);
π¦ DESCRIPTION π¦
Okay so here's the whole vibe. The pclose() function shall close a stream that was opened by popen(), wait for the command to terminate, and return the termination status of the process that was running the command language interpreter. Like, it does the cleanup AND brings you back the receipts. π
BUT. And this is the part you gotta hear, bestie. If a call caused the termination status to be unavailable to pclose(), then pclose() shall return -1 with errno set to [ECHILD] to report this situation. π This can happen if the application calls one of the following functions:
wait()waitpid()with a pid argument less than or equal to0or equal to the process ID of the command line interpreter- Any other function not defined in this volume of POSIX.1β2017 that could do one of the above
In any case, pclose() shall not return before the child process created by popen() has terminated. It is NOT leaving early, periodt. π
If the command language interpreter cannot be executed, the child termination status returned by pclose() shall be as if the command language interpreter terminated using exit(127) or _exit(127). π₯
The pclose() function shall not affect the termination status of any child of the calling process other than the one created by popen() for the associated stream. It minds its own business, fr fr. π
If the argument stream topclose()is not a pointer to a stream created bypopen(), the result ofpclose()is undefined. π
If a thread is canceled during execution of pclose(), the behavior is undefined. π
β RETURN VALUE β
Upon successful return, pclose() shall return the termination status of the command language interpreter. Slay. π
Otherwise, pclose() shall return -1 and set errno to indicate the error. Sad girl hours, but at least you know why. π
π ERRORS π
The pclose() function shall fail if:
ECHILDβ The status of the child process could not be obtained, as described above. (yep, that wholewait()/waitpid()situation from the DESCRIPTION.)
The following sections are informative. iykyk β that means they're the bonus lore, not the binding rules. β¨
π EXAMPLES π
None. bestie there is literally nothing here and that's on purpose. π«Ά
πΈ APPLICATION USAGE πΈ
None. also empty!! iconic of the spec honestly. β¨
π RATIONALE π
Okay this is the director's commentary and it ATE. π
There is a requirement that pclose() not return before the child process terminates. This is intended to disallow implementations that return [EINTR] if a signal is received while waiting. Because think about it: if pclose() returned before the child terminated, there would be no way for the application to discover which child used to be associated with the stream, and it could not do the cleanup itself. So likeβ¦ no. Not allowed. π
ββοΈ
If the stream pointed to by stream was not created by popen(), historical implementations of pclose() return -1 without setting errno. To avoid requiring pclose() to set errno in this case, POSIX.1β2008 makes the behavior unspecified. An application should not use pclose() to close any stream that was not created by popen(). Just don't do it, babe. π
Some historical implementations of pclose() either block or ignore the signals SIGINT, SIGQUIT, and SIGHUP while waiting for the child process to terminate. Since this behavior is not described for the pclose() function in POSIX.1β2008, such implementations are not conforming. Also, some historical implementations return [EINTR] if a signal is received, even though the child process has not terminated. Such implementations are also considered non-conforming. π€
Consider, for example, an application that uses:
popen("command", "r")
to start command, which is part of the same application. The way this works: the parent writes a prompt to its standard output (presumably the terminal) and then reads from the popen()ed stream. The child reads the response from the user, does some transformation on the response (pathname expansion, perhaps) and writes the result to its standard output. The parent process reads the result from the pipe, does something with it, and prints another prompt. The cycle repeats. π Assuming that both processes do appropriate buffer flushing, this would be expected to work. bestie that's a whole conversation between processes, so cute. π¦
To conform to POSIX.1β2008, pclose() must use waitpid(), or some similar function, instead of wait(). Important! Do not use wait() here! β
The code sample below illustrates how the pclose() function might be implemented on a system conforming to POSIX.1β2008.
int pclose(FILE *stream)
{
int stat;
pid_t pid;
pid = <pid for process created for stream by popen()>
(void) fclose(stream);
while (waitpid(pid, &stat, 0) == -1) {
if (errno != EINTR){
stat = -1;
break;
}
}
return(stat);
}
Not me obsessing over how tidy that loop is. π
π«Ά FUTURE DIRECTIONS π«Ά
None. the future is a blank canvas and honestly? we love that for us. β¨
π SEE ALSO π
fork(),popen(),wait()- The Base Definitions volume of POSIX.1β2017,
<stdio.h>
π COPYRIGHT π
Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .
Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .
and that's the whole page bestie!! π this one came to you from IEEE/The Open Group, 2017 (the version and date live down there in the footer normally, but we folded 'em in here instead). go forth and pclose() responsibly, mwah π
β¨πΈπ¦π
π¦ where this page comes from
- alpine 3.22: man-pages-posix 2017a-r0 Β· custom
- alpine 3.23: man-pages-posix 2017a-r0 Β· custom
- alpine 3.24: man-pages-posix 2017a-r0 Β· custom
- arch rolling: man-pages 6.19-1
- arch rolling: man-pages 6.20-1 Β· BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
- nixpkgs unstable: man-pages-posix 2017a
- opensuse-leap 16.0: man-pages-posix 2017a-160000.4.1 Β· SUSE-IEEE
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms