pathname(7)

💖 pathname(7) — a little chat about pathnames 💖

okay bestie, gather round, we're talking pathname(7) from the Miscellaneous Information Manual and honestly? it's giving foundational. it's giving "everything you love is built on this." let's go 🦋

---

✨ NAME ✨

pathname, filename — how pathnames get encoded and interpreted. that's the whole vibe. 💅

---

🌸 DESCRIPTION 🌸

so like, some system calls let you pass a pathname as a parameter. iconic of them. but when you're writing code that deals with pathnames, there's a whole situation you gotta respect:

• there are kernel-space requirements that you must comply with (no negotiating, bestie, this is non-negotiable)
• and there are user-space requirements that you should comply with (soft launch rules, but still, do them)

🎀 the C string thing (iykyk)

the kernel stores pathnames as C strings — that means sequences of non-null bytes, terminated by a null byte. periodt.

and there are a few general rules that apply to all pathnames:

• the last byte in the sequence needs to be a null byte — that's the closer, the mic drop, the end of the sentence 🌙
• any other bytes in the sequence need to be non-null bytes — no sneak-attack nulls in the middle, we don't do that here 💀
• a 0x2F byte ('/') is always interpreted as a directory separator, and it literally cannot be part of a filename. sorry. it's taken.
• a pathname can be at most PATH_MAX bytes long (see limits.h(0p)). and if your pathname is longer than PATH_MAX bytes? not me panicking, because you can split it into multiple smaller pathnames and open it piecewise using openat(2). slay, we love a workaround 🫶
• a filename can be at most a certain number of bytes long, and that number is filesystem-specific (see _PC_NAME_MAX in fpathconf(3)). for maximum portability, programs should be able to handle filenames that are as long as the relevant filesystems will allow. and — also for maximum portability — programs and users should limit the length of their own pathnames to NAME_MAX bytes (see limits.h(0p)). yes, both. the code and the human. we're all in this together 😭

---

🦋 further restrictions (the plot thickens)

some filesystems or APIs may apply further restrictions, like:

• requiring shorter filenames
• restricting the allowed bytes in a filename

so like, don't assume your fave filesystem's rules are everyone's rules. vibe check your filesystem first 💫

and for maximum interoperability, programs and users should also limit the characters they use for their own pathnames to characters in the POSIX Portable Filename Character Set. that's the safe little garden of characters, bestie. stay in the garden 🌸

---

🌈 VERSIONS 🌈

POSIX.1-2024 encourages implementations to disallow creation of filenames containing new-line characters.

Linux does not follow this, and allows using new-line characters. not Linux being the rebellious main character 😌💅

---

👑 SEE ALSO 👑

• limits.h(0p)
• open(2)
• fpathconf(3)
• path_resolution(7)
• mount(8)

go read them, they're all part of the lore 🔥

---

mwah 💋 that's the page. sourced from Linux man-pages 6.20, dated 2026-02-08 — love her, cite her, she ate 💖🎀✨