endprotoent#

Close the protocols database after iteration.

endprotoent is the terminator for the getprotoent / setprotoent / endprotoent iteration triad that walks the system protocols database (typically /etc/protocols). It releases whatever handle or state the system C library kept open for the iteration. You call it once the sequential walk is done; getprotobyname and getprotobynumber do not need it — they open and close the database on each call.

Takes no arguments, returns nothing useful. This is a thin wrapper over the system endprotoent(3) call.

Synopsis#

endprotoent

What you get back#

No meaningful return value. Calling it in list or scalar context yields the empty list / undef-equivalent; nothing you’d want to check. Its value is the side effect of closing the protocols database.

Examples#

Walk every protocol, then close the database:

setprotoent(1);                         # 1 = keep the file open between calls
while (my @p = getprotoent()) {
    my ($name, $aliases, $proto) = @p;
    print "$proto\t$name\n";
}
endprotoent();

Short-circuit mid-walk — endprotoent still closes cleanly:

setprotoent(0);
while (my @p = getprotoent()) {
    last if $p[0] eq 'tcp';
}
endprotoent();

Paired with a direct lookup, endprotoent is unnecessary — name and number lookups manage their own state:

my @tcp = getprotobyname('tcp');        # no endprotoent needed

Edge cases#

Calling without a prior setprotoent / getprotoent: harmless. The system call is idempotent; closing an already-closed database is a no-op on every supported platform.
No arguments accepted: endprotoent $x is a syntax error — the built-in has arity zero.
Not reentrant: the protocols database is a single global resource inside the C library. Two concurrent iterations in the same process step on each other’s state. Use per-thread or per-subprocess walks if you need parallelism.
Platform quirks: behaviour is whatever the host system’s endprotoent(3) does. See perlport for the list of platforms where the network-database routines diverge or are absent entirely.
Stubbed on platforms without /etc/protocols: on systems where the C library has no protocols database, the call is a no-op rather than an error.

Differences from upstream#

Fully compatible with upstream Perl 5.42.