Match a Unix file path
Match an absolute Unix or Linux file path — one or more slash-separated segments of word characters, dots and dashes, starting from the root.
Last updated
Matches
- /usr/local/bin
- /home/ada/.bashrc
- /var/log/app.log
Doesn’t match
- relative/path/here
- /has a space/in it
Why it’s written this way
(?:/[\w.-]+)+ requires one or more repetitions of a leading slash followed by a segment of word characters, dots or dashes — word characters here cover letters, digits and underscore, so ordinary filenames, dotfiles like .bashrc, and dashed names like app-config.json all fit one segment. Anchoring with ^ and $ (plus an optional trailing slash) means the whole string has to be the path, not just contain one.
Requiring the leading slash on every segment is what makes this specifically an absolute-path matcher — a relative path with no leading slash never gets past the very first repetition.
Edge cases to know
- →Spaces in a path fail by design, even though many real Unix filesystems allow them — \w does not include space, so a path like /home/ada/my file.txt only matches up to 'my'. Escape or quote such paths before feeding them to a shell anyway.
- →It has no concept of '.' or '..' as special segments, so /home/../etc matches the same as any other path even though it means something different to the filesystem.
- →Filenames using characters outside [\w.-] — spaces aside, things like @, +, or non-ASCII letters, all valid on most Unix filesystems — will break the match partway through.
Part by part
- ^
- Anchored at the start, so only absolute paths match. A relative path such as src/index.ts is deliberately excluded.
- (?:/[\w.-]+)+
- One or more components, each a slash followed by word characters, dots or hyphens. The + is what requires at least one component after the root.
- /?
- An optional trailing slash, so both /var/log and /var/log/ are accepted.
- $
- Anchored at the end, making this a validator for a whole string rather than a finder within text.
Common mistakes
^/.*$Any string beginning with a slash matches, including a sentence that happens to start with one and a URL path with a query string attached. It tests the first character and nothing else.
^(?:/[\w.-]+)+/?$^(?:/[\w.-]*)+/?$A star rather than a plus inside the component allows empty components, so //var//log matches. Doubled slashes are tolerated by most kernels but are almost always a bug in whatever built the string.
^(?:/[\w.\- ]+)+/?$Adding a space to the class matches paths with spaces, which is legitimate, but then a sentence fragment like "/tmp and then some" also matches in full. If you need spaces, anchor against a known prefix as well.
Questions
Does it match the root directory on its own?
No. The + requires at least one component after the leading slash, so a bare / fails. Add an alternation for it explicitly if the root is a value you expect to see.
Does it match a path with spaces?
No, because the character class excludes them. That is a deliberate trade: allowing spaces makes it much harder to tell where a path ends in free text, and most programmatic paths do not contain them.
Does a match mean the path exists?
No. It confirms the shape of an absolute path only. Whether anything is there, and whether you may read it, are questions for the filesystem rather than the pattern.
Why exclude relative paths?
Because almost anything is a valid relative path, including a single word, so a pattern accepting them matches ordinary prose. Requiring the leading slash is what makes this specific enough to be useful.