How does `cd` work?

Interesting how the author was looking at "cd" obviously sourced from FreeBSD project (perhaps found on a Mac computer running XNU kernel) and then, to investigate further, she consulted the source code for the Linux kernel to learn about "the" chdir syscall.

Would the title "How does 'cd' work in MacOS?" be better for readers wishing to learn, or worse? I wonder.

The blog posts from her friend at jvns.ca have been similarly Linux-centric but never use titles that inform the reader as such, i.e., "How does X work?" versus "How does X work in Linux?"

It makes me ask, how important is it for students to be aware of the Holy Grail of UNIX: portability.

How long should one remain blissfully ignorant of incompatibilities between UNIX-like OS that work against those "still seeking the Holy Grail"?

As a user, the UNIX programmers I admire the most are the ones who understand the value of portability, set it as a goal and through broad knowledge and utmost care can get very close to achieving it, despite the mind-numbing work or the tradeoffs this might entail.

I only discovered this because I implemented a shell specifically by the specification (just for didactic purposes). I was unable to find a modern shell that acted this way, even with passing the "be more POSIXy" options though.

This is a really common way for software to become better.

The pattern of development:

  - Make A   
  - Make B better   
  - A now broken because it had dependencies on B   
  - (maybe) Realize a fundamental pattern that unifies A and B.
  - (maybe) Unify principles so that A and B become lemmas.

This is a very scientific way of working. The truth emerges as the byproduct of keeping all the plates spinning in your model. As long as you remain aware of all the plates, you'll eventually realize something deep. It's also the strongest argument I can think of in favour of rewriting a codebase plan-9 style. Once you have the truth in mind, bake your knowledge for big wins. Baked knowledge can form the foundation upon which you can climb higher.

But many developers don't keep all the plates spinning. If you don't have everything (or some subset) making sense in some unified theory, don't rewrite. Without a unified grand theory, then you can't make something better. This is why I write unit tests — doing so keeps your plates spinning. It's not about proving your language and libraries are doing what is expected (although that's valuable too in some languages without unified libraries) — it's about showing that everything is working together the way your grand theory intends. Unit tests should be written to reject some part of the null hypothesis.

Okay, but now I want to know how it works on something other than (foo)Nix, because that's not an OS space I care about. What about how it works in CP/M or foo-DOS? I've never used a *Nix computer, but I know that I used 'cd' going back to the time of using a TRS-80 CoCo.

I know it's a low-level system call in most on-disk operating systems to change directories. But, for instance, how does it translate physical address to the human-readable name? Do modern (WinXP+) implementations actually take the time to translate folder names from 8.3 to the extended name field? How?

Heck, I'll be dumb enough to ask - why, specifically at the call level, does 'cd\' stick to one level up/down whereas 'cd ' can just pull from just about anywhere? And why, dare I ask, can 'cd' not display like 'tree'?

These are questions about how 'cd' works, to me. Not just, oh, in (foo)Nix it's a system call.

I had some of the same thoughts. But I learned C and Unix a long time ago, back when you could more easily understand the source code. I think we used a very early version of Minix, just a few thousand lines. It was a simpler time ;-).

Coming to it now, with all the layers that have built up -- the side-track for the script that uses tr, and the idiom with ${1+"$@"}, and all the cruft build up within sh(1) -- it must be pretty hard to separate what is incidental from what is fundamental.