[Joker_vD]

Yes? The quote says "tends to", and you still can cd into that directory, albeit not in a single invocation. Windows has similar limitations [0], it's just that their MAX_PATH is just 260 so it's somewhat more noticeable... and IIRC the hard limit of 32 K for paths in non-negotiable.

[0] https://learn.microsoft.com/en-us/windows/win32/fileio/maxim...

[dapperdrake]

Isn’t "cd" a unix syscall , because it changes the process's working directory? There was something written somewhere that it cannot be a unix utility for this very reason, but has to be a shell built-in. The syscall is a "single operation" from the point of a single-threaded process.

What did I get wrong there?

Side note: Missing

  bash$ man 1 cd ;

Useful output

  bash$ help cd ;

[comex]

Yes, it’s a shell builtin that makes the shell execute a chdir() syscall. Therefore it isn’t subject to argument length limits imposed by the kernel when executing processes. But it is still subject to path length limits imposed by the kernel’s implementation of chdir() itself. While the shell may be a GNU project (bash), the kernel generally is not (unless you are running Hurd), so this isn’t GNU’s fault per se.

However, the shell could theoretically chunk long cd arguments into multiple calls to chdir(), splitting on slashes. I believe this would be fully semantically correct: you are not losing any atomicity guarantees because the kernel doesn’t provide such guarantees in the first place for lookups involving multiple path components. I’m not surprised that bash doesn’t bother implementing this, and I don’t know if I’d call that an “arbitrary limitation” on bash’s part (as opposed to a lack of workaround for another component’s arbitrary limitation). But it would be possible.

[Joker_vD]

> What did I get wrong there?

Nothing; you just missed some other considerations. For instance, Linux generally follows POSIX. That's what the 2004 version has to say about chdir's errors:

    ERRORS
    The chdir() function shall fail if:

    ...
    [ENAMETOOLONG]
        The length of the path argument exceeds {PATH_MAX} or a pathname component is longer than {NAME_MAX}.
    ...

    The chdir() function may fail if:
    ...
    [ENAMETOOLONG]
        As a result of encountering a symbolic link in resolution of the path argument, the length of the substituted pathname string exceeded {PATH_MAX}.

However, the following versions of POSIX moved the "length of the path argument exceeds {PATH_MAX}" into the "optional error" part.

[pjmlp]

Not any longer unless you keep default enabled for backwards compatibility with older Windows software.