GETPGRP(2)

✨ GETPGRP(2) ✨

okay bestie, welcome to section 2 of the manual β€” the System Calls Manual πŸ’– β€” and today's main character is getpgrp, the little syscall that tells you which process group you're in. no cap.


πŸŽ€ NAME πŸŽ€

getpgrp β€” get process group πŸ‘‘


πŸ“š LIBRARY πŸ“š

Standard C Library (libc, -lc) β€” she lives in libc, obviously πŸ’…


🌸 SYNOPSIS 🌸

#include <unistd.h>

pid_t
getpgrp(void);

pid_t
getpgid(pid_t pid);

πŸ¦‹ DESCRIPTION πŸ¦‹

so here's the tea β˜• β€” getpgrp() returns the process group of the current process. that's it, that's her whole job.

getpgid() is the more specific sister: she returns the process group of whatever process you point at with pid. and if pid is zero? getpgid() just hands you the process group of the current process instead, which is giving "I got you, bestie" 🫢

now why do process groups even exist, you ask? two reasons, and they're both iconic:

  • they're used for distribution of signals β€” like, signals get broadcast to a whole group at once, it's a whole group chat πŸ“£
  • terminals use them to arbitrate requests for their input: processes that have the same process group as the terminal are foreground and they may read πŸ“–. everybody else? they'll block with a signal if they even try to read. not me getting put in timeout by the tty πŸ’€

this is why programs like csh(1) use this system call to create process groups while implementing job control. and for getting/setting the process group of the control terminal, you'd reach for tcgetpgrp() and tcsetpgrp() instead. iykyk ✨


πŸ”₯ RETURN VALUES πŸ”₯

  • getpgrp() always succeeds. no error path, no drama, she just ate πŸ’…
  • getpgid() on a successful completion returns the process group of the process you specified. otherwise it returns a value of -1 and sets errno to indicate the error. the audacity 😭

πŸ’œ COMPATIBILITY πŸ’œ

okay so this version of getpgrp() differs from past Berkeley versions because she does not take a pid_t pid argument. is that a glow-up or a downgrade? not for us to decide β€” because this incompatibility is required by ISO/IEC 9945-1:1990 (β€œPOSIX.1”). periodt.

and here's the actual rationale straight from the ISO/IEC 9945-1:1990 (β€œPOSIX.1”) Rationale, quoted in full because receipts matter:

4.3BSD provides a getpgrp() system call that returns the process group ID for a specified process. Although this function is used to support job control, all known job-control shells always specify the calling process with this function. Thus, the simpler AT&T System V UNIX getpgrp() suffices, and the added complexity of the 4.3BSD getpgrp() has been omitted from POSIX.1. The old functionality is available from the getpgid() system call.

so yeah β€” old behaviour didn't die, she just moved into getpgid(). glow-up fr fr 🌈


😭 ERRORS 😭

the getpgid() system call will succeed unless:

  • [ESRCH] β€” there is no process whose process ID equals pid. bestie is not in the group chat, she does not exist, nothing to see πŸ’€

πŸ‘€ SEE ALSO πŸ‘€


⭐ STANDARDS ⭐

the getpgrp() system call is expected to conform to ISO/IEC 9945-1:1990 (β€œPOSIX.1”). slay, certified, standard-issue queen πŸ‘‘


🌈 HISTORY 🌈

  • getpgrp() system call appeared in 4.0BSD β€” an OG, a legend, we stan πŸŽ€
  • getpgid() system call is derived from its usage in AT&T System V Release 4 UNIX. she's got lineage, bestie, she's royalty πŸ’–

and that's the whole page, no notes 🫢 this one came from Debian and is dated June 4, 1993 β€” vintage, iconic, still relevant. take care of your process groups out there, mwah πŸ’…βœ¨

πŸ“¦ where this page comes from