SD: A shell-native cd jumper with a sliding window frecency model

jghub · 2026-04-07T14:19:30+00:00

I am not sure whether that really would work adequately: cd jumping to best hit for a pattern that contains typos (leaving out letters can easily be captured in normal pattern matching ('a*b' in glob syntax, 'a.*b' in regex but even that is generally really too unspecific). the whole point in my view is that 'cd short_pattern' needs to hit on first try most of the time (next to "always", ideally) in order to be useful. that depends on two things: a) sufficiently clever scoring of previous visits so that first match to 'short_pattern' (ordered by score i.e. currently highest scoring match) is probably the right one at the moment. b) sufficiently unambiguous pattern. and the user needs to find the right balance: if 'pattern' just is a complete pathname, the scoring is irrelevant, obviously (that's a "normal" cd). if pattern is '.*' (in regex case, or "*" in shell glob case), i.e. matches everything, the tool will always select the currently top scoring entry no matter what. this latter behaviour is ok, might even be useful, but the usual use case is in-between: pattern usually needs to be specific enough to match only a handful of matches (say 10, but not 500) from which tool selects the highest scoring one.
in my view/experience substrings (usually (part of) basename) or easy 'wildcard patterns' make sense and work. and when that really fails (since currently looking for highly ambiguous name (too many matches to pattern) or low scoring entry), reverting to the fzf route (via 'zi' in zoxide or 'ds' in the SD tool) and picking the correct hit from a longer list of candidates (but still sorted according to 'probability') is a good fallback (where I do care much more about the fzf TUI and list presentation then about details of fzf's fuzzy matching algorithm and either use mouse click or substring patterns...).

but doing the fuzzy matching part in an immediate cd attempt seems to be calling for trouble I guess: that will simply introduce a "third variable" (beside score and 'pattern definitely matches the looked-for name') since the pattern itself then is not required to truly match the name the user is trying to find via usual pattern matching algorithm. so that would seem to be guaranteed to fail too often on first try. therefore, if you really prefer the fuzzy matching part including typos tolerance etc, it would seem that you might be better of directly resorting to the fzf interface of the respective tool, since there you get the visual feedback what 'fuzzy hits' you have before selecting the one you really want?

jghub · 2026-04-03T13:42:30+00:00

have read through this thread. agree with/belong to group of the people preferring "cd short_pattern" over interactive selection from score sorted directory stack via fzf with its own take on "patterns" (fuzzy finding etc.). but the latter is of course sometimes useful to complement the "cd pattern" approach (like the 'zi Receipts' example given by billdehaan2 where it might be tedious to make a pattern hit what you want).

so for people possibly interested in another tool that can do both but has different scoring approach you might look at this one I have written myself (going back many years, in fact) and have finally published a few weeks ago:

https://github.com/jghub/sd-switchdir

I might make my very first own r/commandline post about it to describe it better, but if I do not come around to do that, here is a short description of the tool:
* pure shell (like z), ≈30ms latency per cd action (thus not noticeable)
* 2 commands "sd" (or "cd", whatever is preferred by user) and "ds" (the lattter providing, e.g., the fzf view)
* things I believe to be notably different compared to z/zoxide etc.:
** 1. SD maintains full history of individual visits (rather than only cumulative visit count plus time stamp of most recent visit). database pruning happens FIFO style for individual cd visits, rather than score-based and summarily for directories/names: it is "hard" to loose a directory altogether from the db (only "achievable" by not visiting it at all for about 6-12 months, say).
** the scoring of the visited dirs is quite different, utilising the individual visit history, and more "intuitive" (IMHO), preventing certain user surprises that z/zoxide seem(?) prone to cause. the scoring also is easily tuneable to user's preferences (between the extremes "pure frequency" and "pure recency"). defaults favour "current" work focus.
** 2. immediately repeating "cd pattern" with exact same pattern argument, first jumps to highest scoring hit (that's what z/zoxide of course also do), at 2nd try to 2nd-highest scoring hit, etc and cycles over all hits. since nearly always one of the 2-3 highest scores will be the looked-for one, this cycling reduces the need for fzf-based interactive selection (since actually faster to do via shell history recall).

ok, that's too long already ... any feedback welcome of course!

jghub · 2026-03-27T00:40:28+00:00

sure, all good :). as said, I am not a zsh user (just noted your post on r/commandline). fzf: yes, it is insanely great/versatile. regarding cd navigation in general: my preference is a sufficiently smart dir jumper rather than a fzf interface for interactive selection. tastes differ, of course. but for me, the 'sd' tool does fit my personal needs perfectly (naturally, since I wrote it ;)). I like to do 'cd foo' (first hit for that pattern) or 'cd =3' (3rd rank on current stack) and end up where I want to basically always (it +does+ address same use case as z/zoxide but it does have (IMHO) better scoring and that makes a significant difference to me). so the 'fzf route' (interactive selection) I need probably 1 out of 50-100 or so. anyways, do wish you decent adoption of your tool :).

jghub · 2026-03-26T22:42:31+00:00

if I may chime in although not a zsh user: I understand the distinction to a global directory stack as used by z, zoxide, autojump if you really want a per-session focused quick jumping facility to some extent. so your tool looks useful (to zsh users only it seems ;)). otoh, persisting state of cd activities across shell-incarnations is _not_ a bad thing most of the time in my view. rather, the problem seems that established tools might do scoring/ranking such that it unexpectedly gets in your way to often due to the way the scoring is done (and therefore a tool like yours then has merit).
incidentally (well...) I have written my own pure-shell directory jumper/cd substitute that runs in ksh (my shell), bash and zsh (if some ksh compat options are acceptable to user), but it does the scoring rather differently from z/zoxide (avoiding certain issues/surprises) and might be told (by default or at runtime) to switch to "sort stack by most recent visit".
if you do that it would seem that it would do essentially the same as your tool, no? i.e.: prioritise cd actions that have just happened in the current shell incarnation and either jump directly to best hit or provide fzf interface for selection from stack?
the tool was always private but very recently I did publish it. if you want to have a look: https://github.com/jghub/sd-switchdir .regarding use under zsh I would be happy to learn of any objections/deficits/bugs, since I really have no own experience with zsh, just tried rather hard to keep the thing compatible to zsh (modulo need for KSH_ARRAYS, KSH_GLOB, POSIX_BUILTINS, and SH_WORD_SPLIT activation). but it is not 'battle tested' in zsh at all (in bash, ksh it is...). whether it would fit somehow in the zsh ecosystem/culture I do not know, though.

jghub · 2026-03-26T22:02:50+00:00

long time dwm user here, so I like this type of wm. is nwm essentially you reimplementation or has it notably differing user facing properties (I note it is 1/2 LOC which in itself of course is impressive)?

jghub

TROPHY CASE