GETLOGIN(3P)

GETLOGIN(3P) 💖 getlogin, getlogin_r — bestie edition

okay so before we even start — hi, hello, welcome to the POSIX Programmer's Manual 🎀. This page lives in that manual, and there's one thing you need to know up top: the Linux implementation of this interface may differ from what's written here (so go consult the corresponding Linux manual page for the details of Linux behavior, bestie, don't come for me), or the interface might not even be implemented on Linux at all. 🙈 Both things are possible. It's giving "check your local listings."

---

✨ NAME ✨

getlogin, getlogin_r — get login name 🦋

---

✨ SYNOPSIS ✨

#include <unistd.h>

char *getlogin(void);
int getlogin_r(char *name, size_t namesize);

---

✨ DESCRIPTION ✨

So the way getlogin() works is: it shall hand you back a pointer to a string containing the user name that the login activity associated with the controlling terminal of the current process. 🌸 And if getlogin() returns a non-null pointer, then that pointer points to the name the user logged in under — even if there are several login names with the same user ID. Yes, multiple names, one ID, it happens, we don't judge. 💅

Heads up: the getlogin() function need not be thread-safe. 📢 Not me being the chaotic one, that's just what it says.

Now getlogin_r() — she's the organized one 🫶. She shall put the name associated by the login activity with the controlling terminal of the current process into the character array pointed to by name. That array is namesize characters long, and it should have space for the name and the terminating null character. The maximum size of the login name is {LOGIN_NAME_MAX}. ⭐

If getlogin_r() is successful, name points to the name the user used at login, even if there are several login names with the same user ID. Same energy as above, different delivery mechanism. 💖

Both getlogin() and getlogin_r() may make use of file descriptors 0, 1, and 2 to find the controlling terminal of the current process — examining each in turn until the terminal is found. 👀 So if, in this case, none of those three file descriptors is open to the controlling terminal, these functions may fail. And listen: the method used to find the terminal associated with a file descriptor may depend on the file descriptor being open to the actual terminal device, not /dev/tty. That's the lore. Don't argue with the lore. 😤

---

✨ RETURN VALUE ✨

Upon successful completion, getlogin() shall return a pointer to the login name, or a null pointer if the user's login name cannot be found. 🎯 Otherwise, it shall return a null pointer and set errno to indicate the error.

Do NOT modify the string that gets returned. 🙅 The returned pointer might be invalidated, or the string content might be overwritten, by a subsequent call to getlogin(). The returned pointer and the string content might also be invalidated if the calling thread is terminated. It's fragile, okay, handle with care like it's a limited edition. 💀

If successful, the getlogin_r() function shall return zero; otherwise, an error number shall be returned to indicate the error. Clean, simple, iconic. 👑

---

✨ ERRORS ✨

These functions may fail if:

• EMFILE — all file descriptors available to the process are currently open. 😭 every single one. nothing left.
• ENFILE — the maximum allowable number of files is currently open in the system. 🍓 the whole system said "we're full."
• ENOTTY — none of the file descriptors 0, 1, or 2 is open to the controlling terminal of the current process. 💀 nobody's home.
• ENXIO — the calling process has no controlling terminal. 🌧️ literally has no terminal. orphan arc.

The getlogin_r() function may fail if:

• ERANGE — the value of namesize is smaller than the length of the string to be returned including the terminating null character. 🎀 your buffer said "not enough room bestie."

The following sections are informative. (Yes, for real, that's what it says — everything from here on is vibes and context, not requirements. ✨)

---

✨ EXAMPLES ✨

Getting the User Login Name S

okay so this example calls the getlogin() function to obtain the name of the user associated with the calling process, and then passes that information to the getpwnam() function to get the associated user database information. Cute little relay race. 🏃‍♀️💨

#include <unistd.h>
#include <sys/types.h>
#include <pwd.h>
#include <stdio.h>
...
char *lgn;
struct passwd *pw;
...
if ((lgn = getlogin()) == NULL || (pw = getpwnam(lgn)) == NULL) {
    fprintf(stderr, "Get of user information failed.\n"); exit(1);
    }

---

✨ APPLICATION USAGE ✨

Three names associated with the current process can be determined, and honestly this is the part everyone mixes up, so lock in 🔒:

• getpwuid(geteuid()) shall return the name associated with the effective user ID of the process.
• getlogin() shall return the name associated with the current login activity.
• getpwuid(getuid()) shall return the name associated with the real user ID of the process.

The getlogin_r() function is thread-safe and returns values in a user-supplied buffer instead of possibly using a static data area that may be overwritten by each call. 🌈 That's the whole glow-up.

---

✨ RATIONALE ✨

The getlogin() function returns a pointer to the user's login name. The same user ID may be shared by several login names. 👯 If it is desired to get the user database entry that is used during login, the result of getlogin() should be used to provide the argument to the getpwnam() function. (This might be used to determine the user's login shell — particularly where a single user has multiple login shells with distinct login names, but the same user ID. 😵‍💫 yes, one human, many shells, many names, one ID.)

The information provided by the cuserid() function — which was originally defined in the POSIX.1‐1988 standard and subsequently removed 🪦 — can be obtained by the following:

getpwuid(geteuid())

while the information provided by historical implementations of cuserid() can be obtained by:

getpwuid(getuid())

The thread-safe version of this function places the user name in a user-supplied buffer and returns a non-zero value if it fails. The non-thread-safe version may return the name in a static data area that may be overwritten by each call. 💅 same story, told twice, because history.

---

✨ FUTURE DIRECTIONS ✨

None. 🌵 nothing. no plans. the roadmap is empty. periodt.

---

✨ SEE ALSO ✨

• getpwnam()
• getpwuid()
• geteuid()
• getuid()

The Base Definitions volume of POSIX.1‐2017, <limits.h>, <unistd.h> 📚

---

✨ COPYRIGHT ✨

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .

---

and that's the whole page bestie 🫶 this one's from IEEE/The Open Group, dated 2017, and it's the GETLOGIN(3P) page — so if you ever forget what year it's from, it's 2017, and if you ever forget who made it, it's IEEE and The Open Group. slay, go get that login name. 👑💖