How does `cd` work?

> If /usr/bin is on a case-insensitive filesystem, and you execvp("CD", ...)

That seems like fairly rare edge case, considering that UNIX typically had case-sensitive file-systems, or rather handled filenames as opaque blobs. I wonder what actual system caused the need for case folding? Maybe HFS?

if you use zsh on the other hand..

  % which which
  which: shell built-in command

> I decided to dive into the code for the Bourne shell to see what I might be able to figure out about these builtins. I came across the definition of the cd builtin here. (link to: http://git.savannah.gnu.org/cgit/bash.git/tree/builtins/cd.d...)

no, you came across the definition of bash's 'cd' builtin there..

On FreeBSD with a source checkout, the definition of /bin/sh's (the 'ash' shell, https://en.wikipedia.org/wiki/Almquist_shell) cd builtin is in:

/usr/src/bin/sh/cd.{c,h}

or, on the web:

https://svnweb.freebsd.org/base/head/bin/sh/cd.c?revision=32...

similarly, most anything in base is available in:

/usr/src/{path with '.' instead of slash}/{command name}

which is by the way, very handy, and in combination with having all your self built packages in /usr/ports/distfiles/.tar. a big plus of running a BSD system from source..

I have had this snippet in my `.bashrc` for years. No idea who to give credit to:

    #    eg. save mc
    #    cd mc # no '$' is necessary

    if [ ! -f ~/.dirs ]; then  # if doesn't exist, create it
        touch ~/.dirs
    fi

    alias show='cat ~/.dirs'
    save (){
        command sed "/!$/d" ~/.dirs > ~/.dirs1; \mv ~/.dirs1 ~/.dirs; echo "$@"=\"`pwd`\" >> ~/.dirs; source ~/.dirs ;
        source ~/.dirs  # Initialization for the above 'save' facility: source the .sdirs file
    }
    source ~/.dirs  # Initialization for the above 'save' facility: source the .sdirs file
    shopt -s cdable_vars # set the bash option so that no '$' is required when using the above facility

What this does is, whenever you're in a directory that you'd like to "bookmark" as you'd call it. Just type `save whatevername`. Then, when you navigate somewhere else you can type `cd whatevername` and it'll change you back there. It's simply adding to this ~/.dirs file and so overwriting is taken care of by just saving the same name in a new (or the same) directory. It just appends a line.

Also, you can just type `show` and any point and it'll tell you what you've saved and where.

The nicest thing is that this persists with new logins (the only drawback is that other shells that are running don't get the update automatically).

On the one hand, I admire the search for knowledge, taking things apart and seeing how they work. On the other hand, this seems a bit cargo-cultish. It's as if I took apart a record player, trying to see how it plays music, and I told you it works because the motor turns the the record.

In this case, the author got tangled in the shell script and code, and totally missed the whole subtlety and complexity of the Unix architecture. I expected to see something about the processes, file system, and directory entries. Even after the author added key information that was emailed to him by a reader, he didn't really follow up or try to understand more. I understand that not all coders have or need a degree in computer science, but it really surprises me what this author doesn't know (and doesn't know he doesn't know).

Another example from his next blog about 'ls': "I’ll admit, scrolling through all this C-code can be a little tiresome. Oh, how I miss the days when all I had to do was read JavaScript source! Because C gives you so little out of the box, a lot of the code that you end up reading is not that interesting. It’s largely the kind of stuff that higher level languages implement in their standard library." [https://blog.safia.rocks/post/171381157060/looking-into-ls]

Here's a book about Unix, among many (I got this one as a CS graduation present): https://www.amazon.com/Magic-Garden-Explained-Internals-Rele...