[1718627440]

I see. Sounds interesting, I guess it is just not for me.

How does it cope with the directory stack, what happens when I do a 'cd -' after using sd, where does it take me?

I mean fundamentally a filesystem is just a namespace and I can order it like the hell I want, it also supports different types of aliasing.

[jghub]

Sure, needs and tastes differ.

'cd -' behaves exactly as it always does. Functionality-wise, when you use the 'sd' wrapper (which shadows the builtin by default), it treats the standard cd behavior as a prioritized subset. If you provide a valid path -- 'cd path', 'cd ~-', 'cd -', or 'cd ..' -- it resolves that first and behaves as it always has. If you only used those commands, you would never even notice sd is there.

The power comes when you choose to use it: you are free to try 'cd src' and see if it moves you across the filesystem to the desired location based on your recent activity.

Regarding aliases: one can certainly manage navigation with symlinks and aliases. Historically, that was actually my incentive to write sd. I had dozens of symlinks and ~50 aliases like alias cdsrc='cd /path/to/deeply/buried/dir'. Maintaining that manual list became increasingly annoying. sd solved that by replacing manual curation with a sliding window weighted summation of my actual movements. In a sense, it essentially replaces manual aliases with pattern matching against the dynamically changing directory stack based on what I’m currently focused on.

[1718627440]

I meant when I do:

    cd ...
    sd ...
    sd ...
    cd -

Does it undo the last sd or the last cd?

When I do a pushd, does sd change the odds, to the time I was in that directory? Does sd have a replacement for pushd?

[jghub]

To answer your specific questions on shell integration:

cd - behavior: It undoes the last directory change irrespective of whether you did it with builtin cd or via sd. If you do "sd project-a" and then "cd -", you go back to where you were before. The sd function is a "thin" wrapper that ultimately executes "command cd <pathname>", so it respects the shell's native $OLDPWD logic perfectly.

pushd and "odds": In its current implementation, sd only records a visit when you specifically use the sd command (or its cd alias) to move. If you use pushd or popd directly, sd isn't invoked and doesn't "see" that movement. This keeps manual stack operations entirely separate from the automated ranking. To be clear: the shell managed pushd/popd stack is distinct from the dynamic score-sorted directory stack maintained/utilized by sd. Personally I simply do not have any more use for the former so would argue that sd not seeing cd actions initiated by push/popd is not an issue for the tool.

pushd replacement: sd doesn't replace pushd/popd/dirs. Think of pushd as a manual bookmarking system and sd as a temporal index. They coexist: pushd is for explicit, manual stack management (presuming you still want/need it in addition to sd), while sd is for "get me to this project's source" jumps using shorthand.

The design goal is to be a "well-behaved citizen" of the shell. It doesn't break standard invariants; it just adds a shorthand layer that requires zero manual maintenance.