endpwent#
Close the passwd-database iterator opened by getpwent or setpwent.
endpwent is the companion teardown call for a passwd-file walk. After iterating the password database with repeated getpwent calls, endpwent releases whatever per-process state the C library allocated to hold the iteration cursor (an open file descriptor on /etc/passwd, a cached buffer for NSS, a connection to nscd / sssd, an LDAP session, depending on the host’s name-service configuration). It takes no arguments and wraps the system endpwent(3) call directly.
Synopsis#
endpwent
What you get back#
A single boolean value. The return is rarely checked - on every platform PetaPerl supports, endpwent cannot meaningfully fail, and real code treats it as a void call.
Global state it touches#
endpwent mutates no Perl-visible variable. The state it clears is entirely inside the C library: the per-process passwd iterator, shared with getpwent and setpwent (and, on some systems, with getpwnam / getpwuid when those happen to reuse the same underlying stream). Calling endpwent in one thread affects every other thread in the same process - the iterator is per-process, not per-thread.
Examples#
Standard iterate-then-close idiom:
setpwent;
while (my @ent = getpwent) {
my ($name, undef, $uid) = @ent;
print "$uid\t$name\n";
}
endpwent;
Ensure the iterator is closed even if the loop exits early:
setpwent;
eval {
while (my @ent = getpwent) {
my ($name, undef, $uid, $gid) = @ent;
die "found it\n" if $uid == $target;
}
};
endpwent; # always run, regardless of how the loop ended
Pair with a local guard so nested code cannot leave the iterator half-walked:
sub each_user {
my $cb = shift;
setpwent;
my $guard = Guard::guard { endpwent }; # or a manual eval-and-rethrow
while (my @ent = getpwent) { $cb->(@ent) }
}
endpwent with no prior iteration is harmless:
endpwent; # no-op on a fresh process
Edge cases#
No arguments, no parentheses needed.
endpwentis a named unary operator with zero arguments; write it bare.endpwent()is accepted but adds nothing.Idempotent. Calling
endpwenttwice in a row, or calling it before anygetpwent/setpwent, is defined as a successful no-op on every supported platform.Does not invalidate records you already fetched. Arrays and hashes returned by earlier
getpwent/getpwnam/getpwuidcalls are plain Perl data and remain valid afterendpwent- only the iterator cursor is closed.Thread safety. The iterator is process-wide. If two threads are walking the passwd database simultaneously,
endpwentcloses the shared cursor for both - neither thread will get the full record set. Use a lock around the wholesetpwent/ loop /endpwentblock when iterating from threads.Name-service backends. On hosts using LDAP, NIS,
sssd, or any other non-flat-file backend,endpwentmay release a network handle. A long-running daemon that iterates the passwd database periodically should callendpwentat the end of each pass rather than leaking one handle per pass.Not a forced cache flush.
endpwentcloses the iterator; it does not flush the C library’sgetpwnam/getpwuidcaches. A subsequentgetpwnammay still return a cached record.
Differences from upstream#
Fully compatible with upstream Perl 5.44.
See also#
setpwent- rewind or open the passwd-database iterator before a walk; pairs withendpwentas the open/close bracketgetpwent- fetch the next record from the iterator thatendpwentclosesgetpwnam- direct lookup by login name, independent of the iterator in most implementationsgetpwuid- direct lookup by numeric UID, same independence note asgetpwnamendgrent- analogous teardown for the group-database iterator; the two are almost always called together