endnetent#

Close the networks database after iteration.

endnetent releases the resources held by the networks database — typically the /etc/networks file or its NSS-backed equivalent — that were opened implicitly by the first call to getnetent, getnetbyname, or getnetbyaddr, or explicitly by setnetent. After endnetent the iteration cursor is gone; a subsequent getnetent starts a fresh sweep from the top of the database. It is a thin wrapper over the system C library’s endnetent(3).

Synopsis#

endnetent;
endnetent();

What you get back#

A system-defined true value. The C function returns void; Perl surfaces a placeholder so the call can stand as a statement. Do not compare the return value against anything — there is nothing useful in it.

Global state it touches#

endnetent operates on the process-wide networks-database cursor owned by libc. That cursor is shared with getnetent, getnetbyname, getnetbyaddr, and setnetent; a call here invalidates the iteration state those functions depend on. No Perl special variable is touched.

Examples#

Paired with setnetent and getnetent for a complete sweep of the networks database:

setnetent(1);                       # stayopen = 1
while (my @net = getnetent()) {
    my ($name, $aliases, $addrtype, $net) = @net;
    print "$name\t$net\n";
}
endnetent();                        # release the cursor

Close after the handful of lookups you actually needed, so the database file does not stay open for the rest of the program:

setnetent(0);
my @loopback = getnetbyname("loopback");
my @link     = getnetbyname("link-local");
endnetent();

Safe to call when the database was never opened — libc treats it as a no-op:

endnetent();                        # harmless on a fresh process

Edge cases#

No arguments, list-operator precedence. endnetent takes no arguments but parses as a list operator, so a stray term after it is swallowed: endnetent $x is endnetent($x) and produces a “Too many arguments” compile-time error. Write endnetent; or endnetent();.
Repeated calls. Calling endnetent twice in a row is a no-op on the second call on every libc we target. Do not rely on it raising an error.
Interleaving with other DB iterators. The networks cursor is independent of the cursors used by getpwent, getgrent, gethostent, getprotoent, and getservent. endnetent does not close those — call the matching end*ent for each iterator you opened.
Forking between setnetent and endnetent. The cursor lives in the parent’s libc state; a child inherits it at fork time but further getnetent calls in either process will desynchronise. Close and re-open in the child.
NSS backends. On glibc the networks database routes through NSS, so the meaning of “close” depends on the configured service (files, nis, ldap, …). User-visible behaviour — iteration restarts on the next getnetent — is the same; the cost of endnetent is not.
Thread safety. The libc networks cursor is a single process-global resource. pperl does not serialize access to it; a program that iterates the networks database from multiple threads must do its own locking.

Differences from upstream#

Fully compatible with upstream Perl 5.42.