getlogin#

Return the login name of the user associated with the controlling terminal.

getlogin wraps the C library function of the same name. On Linux it consults the kernel’s record of who owns the current controlling terminal — traditionally recorded in /var/run/utmp — and returns that name as a string. It answers the question “who logged in on this tty?”, which is not the same question as “who is running this process?”. A process that has changed its real or effective UID, or that has no controlling terminal at all (a daemon, a cron job, a container entrypoint), will usually see getlogin return the empty string or undef.

Synopsis#

my $name = getlogin;

What you get back#

A string — the login name recorded for the controlling terminal — or the empty string / undef when no such record is available. Treat both empty-string and undefined as “unknown” and fall back to a UID-based lookup:

my $login = getlogin || getpwuid($<) || "Kilroy";

Using || here is deliberate: the empty string and undef both mean “no answer” and both should trigger the fallback.

Global state it touches#

Reads $< indirectly only via the idiomatic getpwuid fallback above; getlogin itself takes no arguments and consults no Perl variables.
Sets $! on the underlying system-call failure paths exposed by the C library.

Examples#

The canonical who-is-this-user pattern, robust against detached sessions and UID changes:

my $login = getlogin || getpwuid($<) || "Kilroy";
print "hello, $login\n";

Bare call in a shell-attached script:

my $name = getlogin;
print defined $name && length $name
    ? "tty owner: $name\n"
    : "no controlling tty\n";

Contrast with getpwuid, which answers a different question — “who is the effective user running this code?”:

my $tty_user  = getlogin           // "";
my $proc_user = getpwuid($<);
print "tty=$tty_user proc=$proc_user\n";
# After `sudo -u bob script.pl`, tty_user is your login,
# proc_user is "bob".

Inside a daemon or a cron job there is no controlling terminal, so getlogin has nothing to report:

# running from cron
my $name = getlogin;
# $name is "" or undef; always pair with a getpwuid fallback

Edge cases#

No controlling terminal: daemons, systemd services, cron jobs, container entrypoints, and anything started without a tty see the empty string or undef. This is the common case outside interactive shells — always provide a fallback.
sudo and su: getlogin returns the original login name (the tty owner), not the target user. After sudo -u bob script.pl you get your own login, while getpwuid with $< returns bob. Pick the one that matches the question you are actually asking.
Not an authentication primitive: the record getlogin reads can be forged or stale; a process that inherits a tty from an unrelated session can see a name that has nothing to do with its own credentials. Never gate privileged behaviour on the return value. Use getpwuid on $< / $> instead.
Empty string vs undef: platforms differ on which they return when there is no record. The || fallback handles both; a defined-only check does not.

Differences from upstream#

Fully compatible with upstream Perl 5.42.